Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS boot.efi developer's thread

casmock said:
It works on my 2,1 (1,1) setup.

Maybe you forgot that you have to issue 'chflags nouchg /System/Library/CoreServices/boot.efi' before replacing it with a fresh copy of 'boot.efi'. Make sure you issue 'chflags uchg /S/L/CS/boot.efi' once you copy 'boot.efi'.

EDIT:
My bad, I didn't see your edit.
Click to expand...

Thnx, It's OK :)

But I never do 'chflags uchg /S/L/CS/boot.efi' ... and it always works as is. I'm using Path Finder, never tried replacing with Finder.
boot.efi that i'm copying is 644, if that matters.
 
Barkitecto said:
Sorry but how did you manage to update from 1.1 to 2.1 and to make it recognaize the graphic card. Can you please explain it to me.

Got the same machine and card, just 32gb of RAM in it. But do not recognaize the processor either (i upgrade them a few months ago)
Click to expand...

As mentioned above, a simple firmware update takes a 1,1 to a 2,1.

As for the AMD R9 280x video card, you just drop it in and it works. There are a number of video cards that will work in a 2,1. Just make sure that you get a card that has 32-bit EFI or byte-code EFI (aka EBC). AMD cards have builtin video drivers in 10.11, but if you use a newer NVIDIA card, you'll have to use NVIDIA's web drivers. You can also use many video cards that don't bother with EFI, but you won't have a boot screen and may not be able to make full use of all the card's features.

I also replaced the original processors with 2 x X5365 (3 GHz Woodcrest Xeon). It's not a terribly hard task, but it does take time, a comfort level with gutting the machine, and a long hex tool.
[doublepost=1463460913][/doublepost]
RogerX said:
Thnx, It's OK :)

But I never do 'chflags uchg /S/L/CS/boot.efi' ... and it always works as is. I'm using Path Finder, never tried replacing with Finder.
boot.efi that i'm copying is 644, if that matters.
Click to expand...

That flag is supposed to be set for /S/L/CS/boot.efi. Maybe 10.11 doesn't check or maybe it doesn't care?
 
casmock said:
That flag is supposed to be set for /S/L/CS/boot.efi. Maybe 10.11 doesn't check or maybe it doesn't care?
Click to expand...

Thnx.

I'm not really an expert, but since it is working this way, I won't try to flag yet, unless someone prove it is necessary.

BTW, I also run RepairPermissions and I get this:

User differs on "usr/standalone/i386/boot.efi", should be 0, user is 99.
Group differs on "usr/standalone/i386/boot.efi", should be 0, group is 99.
Unable to set owner & group on "usr/standalone/i386/boot.efi". Error 1: Operation not permitted
Unable to set permissions on "usr/standalone/i386/boot.efi". Error 1: Operation not permitted

But still working without problems.... for now..
 
Last edited:
RogerX said:
Thnx.

I'm not really an expert, but since it is working this way, I won't try to flag yet, unless someone prove it is necessary.

BTW, I also run RepairPermissions and I get this:

User differs on "usr/standalone/i386/boot.efi", should be 0, user is 99.
Group differs on "usr/standalone/i386/boot.efi", should be 0, group is 99.
Unable to set owner & group on "usr/standalone/i386/boot.efi". Error 1: Operation not permitted
Unable to set permissions on "usr/standalone/i386/boot.efi". Error 1: Operation not permitted

But still working /w problems.... for now..
Click to expand...

You will probably have to boot into recovery mode (command+R at startup) and run Disk Utility from there since SIP won't allow you to effect changes in system directories on a volume that you booted from.
 
casmock said:
You will probably have to boot into recovery mode (command+R at startup) and run Disk Utility from there since SIP won't allow you to effect changes in system directories on a volume that you booted from.
Click to expand...

I disabled SIP some time ago, but for sure, will check again.

Thnx.

EDIT:

I guess updating OS, reenable SIP.
 
So Sierra DP has come and Pike started to work on a Sierra-compatible branch of boot.efi:
https://forums.macrumors.com/thread...1-2-1-and-macos-sierra.1977271/#post-23011268

I compiled latest commit (162fe51) and result is exactly that same as with latest El Capitan boot.efi version.
KP.

Screenshot attached.

20160614_162648.jpg
 
  • Like
Reactions: nounousomes
using the latest update (time 11PM my time) there I got deeper into the boot sequence but it still panics on the upside it does find root device and since im booting from a USB iPod this does indicate USB should still work on the Mac Pro 1,1/2,1 :) attached is a panic log (in this boot i tried safe mode the panic was slightly different in normal mode but it panicked at the same place but i dont have time to go grab that sadly) forgot to mention this was booting the installer.

hope this helps
 

Attachments

  • macOS-Panic-log-macosxbootloader_black_3843152.txt
    5.7 KB · Views: 692
Last edited:
Hello, gentlemen. If I may, I'd like to point out that several users at the VMware Fusion forums (https://communities.vmware.com/message/2602662#2602662) have commented they're having problems to install Sierra as a virtual machine on Fusion 8.1.1. Obviously, this is hardly the same "hardware" as our old Mac Pros 1,1, 2,1 (and now 3,1), but perhaps the temporary roundabout found by VMware staff (http://www.mikeroysoft.com/macos-sierra-on-fusion-8/) will benefit us as well. It involves using not the Developer Preview of Sierra, but creating install media from it. Perhaps, for now, install tests ought to be carried out using automatically created install media or creating the media ourselves the usual away a-la-Tiamo/Jabbawok/Hennessie2000/Holbrook. Chances are the boot process will get further that way.

Unfortunately, I can't test this myself now, but if any of you has the time to try and report back to this forum or to https://forums.macrumors.com/threads/2006-2007-mac-pro-1-1-2-1-and-macos-sierra.1977271, it would be great.
 
With commit d5e7277 KP'ed again.
Verbose mode scrolled so fast that I couldn't catch the whole output before it rebooted.
Attaching KP log.
 

Attachments

  • KP_d5e7277.txt
    1.5 KB · Views: 313
So I've patched two nice modestly-priced MacPro 1,1 machines to replace our aging his-and-hers G5 quads, driven mostly by the browser situation becoming intolerable. These now have 2,1 firmware, 8x3GHz "Big Jim" SLAED CPU's, SSD's, gobs of RAM, and ATI HD4870's, and they're working beautifully, running 10.11.5, couldn't be happier.

... Except for Time Machine backups to our file server. Turns out both machines have exactly the same hardware UUID's, 2B12FE1B-1090-593B-B740-2E45F371D1E4 to be exact, and the UUID is used as part of the Time Machine database key, so they fight over the same backup set. Which is not appreciated! Googling shows that it seems like all patched MP's use the same HW UUID.

All attempts to get them to have different UUID's have failed, I even went so far as to write a C program that did a find/replace on the entire SSD volume, replacing 40-odd occurrences. It worked fine, but it booted back up with this UUID anyway.

So, do the patched boot.efi files somehow force a particular UUID? Is there any way to get them to not do this? The machines do not have the same HW UUID's when running 10.6 or 10.7, for example.
 
Hi guys,

Please find attached a copy of my pikify3.2 script bundle. It is modified for 10.12 Developer Preview. It currently has Pike's
macosxbootloader_black_3843152 and macosxbootloader_grey_3843152 efi files.

My script uses the boot.efi file in the folder, and this is currently a copy of of the grey version.

Usage: sudo ./createpikeinstallmedia /Volumes/Untitled
(where /Volumes/Untitled is a small disk partition, or a USB memory stick - use a path to suit your environment)

On first run, the script modifies the "/Applications/Install 10.12 Developer Preview.app", and then uses the embedded createinstallmedia command line tool.

On subsequent runs it will detect if the "Install 10.12 Developer Preview.app" has already been modified, and will present an option to reset back to the Apple-shipped version.

I use this script to build install media.

Attached is a video of my first attempt. Hopefully it's clear enough to see the verbose output of my attempt to boot from the install media (it tends to take a short while before Youtube's automatic processing gets the high-def version into place)...

md5 of pikify3.2.v01.zip is 06fd8f4043ab4debe9f8fb2b0274ef19

 

Attachments

  • pikify3.2.v01.zip
    1.9 MB · Views: 5,990
I have no idea whether Pike has some plans for the SSE 4.1 problem, but there seems to be a new commit of boot.efi. Have any of you given it a try?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back