barrykn / big-sur-micropatcher

A primitive USB patcher for installing macOS Big Sur on unsupported Macs
1.24k stars 174 forks source link

micropatcher.sh doesn't find/detect 11.0.1-11.1 USB installers created with installer app from MAS; + issues with multiple installer partitions on one USB drive #148

Open joaofrgomes opened 3 years ago

joaofrgomes commented 3 years ago

Help!

I was thinking of upgrading my installer to macOS Big Sur 11.1 and I screwed up… I formatted it before checking if there were any updates, and now, I'm trying to recreate it with the 11.0.1 GM release and I can't, for the life of me, get micropatcher.sh to detect my freshly recreated installer with createinstallmedia.

I tried just running the script, pointing it manually to my volume, doing so on a different machine, doing it under a VM, the works. It. doesn't. work. I'm afraid my laptop might be borked in some way and I won't have the option for doing a PRAM reset, as I couldn't make it bootable again. Please help!

radairiz commented 3 years ago

I think this download link is for Big Sur 11.0.1 (20B50) http://swcdn.apple.com/content/downloads/19/41/001-83532-A_LN5NT1FB2Z/o4zodwe2nhyl7dh6cbuokn9deyfgsiqysn/InstallAssistant.pkg

joaofrgomes commented 3 years ago

Here's the thing, I was using the original MAS download for 11.0.1… I fished it out from a Time Machine backup, and createinstallmedia works just fine.

I will give yours a try, however. I'll see how it goes and let you know. Thanks!

joaofrgomes commented 3 years ago

Hi again @radairiz! I can confirm that not only did the installer derived from the InstallAssistant.pkg whose download link you sent me work just fine for recreating the USB installer via createinstallmedia, but said installer was also properly patched by @barrykn's micropatcher at the very first try and without me even having to manually point it to the proper volume. So, it seems I can again rest assured that a PRAM reset or other shenanigans won't leave me out of a functioning, up-to-date-ish laptop. Thanks! 👍

joaofrgomes commented 3 years ago

Uh-oh. Now I'm getting the same crap with install-setvars.sh. What the heck is wrong with this thing?

Could it be my USB stick's fault? It does have a tendency to bork itself from time to time, especially when I end up fiddling with partitions (and I did create an extra 16 partition for a vanilla 11.1 installer, though it's sitting empty at this point and has a different volume name), but it seems to be working fine now (it properly mounts, it appears in Disk Utility, and I can see it perfectly also in System Information and through diskutil).

This thing just seems to be cursed, or something. [Edit #2: It still does, but not in the way I expected, and at least now I can deal with it…]

Edit, for reference: I'm getting a “line 144: mount: command not found” error, by the way. Edit #2: All of this may have been a VERY weird bug/issue with Terminal.app itself! I thought to myself, if the script needs to access the hidden EFI partition on my USB installer, why not mount it myself? To my amazement, I could check diskutil's manpage but couldn't even issue a basic “diskutil list” command. I closed that Terminal window and opened a new one, and whaddyaknow, install-setvars.sh is now working just a-ok. At this point, this does make me wonder just how buggy Big Sur and its first-party apps are…

joaofrgomes commented 3 years ago

Hey again!

I got all confident with my newly-recreated and patched macOS 11.0.1 installer, and figured that I might as well try and create and patch an 11.1 one on the second partition on my USB drive, in order to perform the update from there (I read somewhere that direct updates from System Preferences aren't yet working and, indeed, my MBP fails to find/list said update).

Unfortunately, I ran into this very issue again, so I thought I'd prevent further clutter on the issues list and forego repeating myself, and just reopened this one and amended the title…

Maybe this is a stupid question and someone else posted it elsewhere, but I'm getting the same behaviour specifically with a macOS 11.1 USB installer created with the latest “Install macOS Big Sur.app”, as downloaded through the Mac App Store.

Since that was the same thing I did before with – if I wasn't mistaken and didn't accidentally get the two installers mixed in the process of restoring the original one from Time Machine – a 11.0.1 installer downloaded from the MAS, was that the problem all along (in which case, I'd kindly ask @radairiz, @barrykn or any other user to confirm if this direct link, just like the one linked above for 11.0.1, is more likely to work: http://swcdn.apple.com/content/downloads/00/55/001-86606-A_9SF1TL01U7/5duug9lar1gypwunjfl96dza0upa854qgg/InstallAssistant.pkg ), or is v0.5.1 of the patcher just incompatible with macOS 11.1 at this point and I'm wasting your time and mine?

Anyway, I'll try again with this one, so if this indeed fixes my issue you may wish to add this workaround to the documentation. Also, FWIW, I have all my Macs set up not in English, but in Portuguese. That usually isn't an issue, but I've had my fair share of problems when installing Wacom drivers in the past because of localisation (I had to temporarily set my system language to English so it could finish installing), so there's that.

All the best, kudos for your work, and thanks in advance for your help!

joaofrgomes commented 3 years ago

Quick update: indeed, running createinstallmedia from the “Install macOS Big Sur.app” unpackaged/installed from the InstallAssistant.pkg downloaded directly from Apple's servers worked just a-ok, and produced a 11.1 USB installer compatible with both micropatcher.sh and install-setvars.sh, on first try!

[Now I entered this voodoo-like state of mind – kind of like how Mac users were always, back in the day, repairing permissions and resetting the PRAM and SMC and whatnot for no good reason –, so I quit and relaunched Terminal between all operations except when it came to running your two scripts, which I did in one go; maybe all that relaunching was overkill, or perhaps I could've taken it one step further and tried all possible combinations to try and isolate the issue, but I'm multitasking and very short on time here so I did what made sense to me considering all my earlier attempts and successes. And what do you know, it worked!]

Now, on to installing this update on the sacrificial, external SSD from which I usually run macOS betas and on which I perform all these tests. It's a perfect candidate, because I just booted my MBP off of it and confirmed it's still running 11.0.1 with your patch, and besides the odd application installation or two for compatibility testing purposes, it also went largely untouched since Big Sur was released, so there are almost no extra variables to account for there.

I'll keep you updated all the way until I have this thing running on said MBP's main internal SSD and tested it to a point where I'm fairly confident it's stable enough for a daily driver (likely during vacation, or shortly afterwards)… Stay tuned!

Until then, yep, maybe you should look into this whole MAS installer debacle. I don't know what's so special about my setup – by the way, I should remind you that I also tried running the script on my MBP running Big Sur 11.0.1, and on an updated High Sierra VM, both to no avail, so clearly the issue must lay either with the MAS installers themselves or with your scripts –, but who's to say there aren't other people facing the same issue and just giving up on updating to Big Sur altogether because they assume something's totally broken or incompatible? MAS is, indeed, the macOS installer source of choice for lay people and even for many of those brave enough to hack their Macs to bits (sometimes quite literally so)…

All I know is that even though I'm perfectly comfortable with direct downloads and whatnot, I've always had a preference for MAS installers – it's not that I don't trust URLs that are also very obviously Apple's, but still – and consistently ran createinstallmedia from those without a hitch, both on supported machines or using various hacks (by dosdude1, MPF, RMC…). In any case, even when the OS installation itself failed while using the latter, I don't recall the USB installer creation/patching phase being the breaking point (though I can't be sure that it wasn't, either, so I'll take this new information into account and test for that if I run into further issues with El Cap–HS-level vintage machines at some point).

This is completely new territory for me, as you can see. Anyhoo, If you want further help with isolating this bug, do hit me up after I finish my first semester (around the end of February).

joaofrgomes commented 3 years ago

Another update (and the plot thickens): one of the installers seems to be running fine, but lingered on for a bit at the “Examining volumes” step right at the very beginning. As for the other, it does boot to an Apple logo and progress bar, but consistently blacks out and runs into a KP after a few seconds.

Seeing how macOS installer volumes made with createinstallmedia are always given the same generic name when blessed, which obviously overrides my custom partition/volume names in the boot selector, and that I can't pick them from the Startup Disk on the installer (I haven't yet tried doing just that with the latest USB installers from a full macOS installation, on System Preferences), the only way I might figure out which was which would be by either wiping one of them altogether or booting into Single User Mode and manually picking my boot volume from the device/volume tree, but heck, either I never did that or haven't done so in ages.

Luckily, volumes seem to appear always in the same order in the boot selector, and guess what, I checked the version on the installer that doesn't KP by running sw_vers -productVersion on Terminal, and I got…

11.1 ??!

I was half-expecting the installer – which, mind you and as I said, I had recreated for safekeeping, except I didn't think to test booting from it… whoops! – for the very much compatible 11.0.1 to boot just fine and the borked installer to be the 11.1 one, yet here we are. Either 11.0.1 just borked itself in the process of creating the second 11.1 one – which seems a bit weird, as I made a point of never having both mounted at the same time to avoid any potential interactions/conflicts – or never worked properly in the first place, but either way I'm not redoing any of this again (or not right now, and hopefully never, but if you really want me to later on, do tell).

Also, speaking of partitions, I only see a single EFI Boot one, from the patcher, in the boot selector. It seems to work fine for its purpose of resetting patched PRAM values, but since I haven't booted from my main internal drive again just yet, I can't be entirely sure. Fingers crossed!

Oh well. I'll still try installing 11.1 onto the external SSD, just for the heck of it. If it works, I guess I could just wipe the borked 11.0.1 installer and put a Mojave or a couple of 8 GB-sized vintage ones in its place for good measure (Catalina, with its lack of 32-bit support, will end up being an all but useless transitional affair for most people anyway, and I'll only be keeping patched versions of it on machines which won't run Big Sur decently).

Speaking of which, I've always put multiple installers on large-ish external drives (my Swiss-Army-knives of choice being two 32 GB SanDisk Cruzer Blades filled with vintage installers and a cutesy, also 32 GB EMTEC sliding USB-A+USB-C port affair for the latest-and-greatest OS for USB-C machines and modest data transfers, but I've been doing this sort of thing since as far back as 2007, when I cloned a Leopard installer DVD image onto a FW400 LaCie HD to then extraordinary effect and speed gains), some of them even patched, but IIRC it's the very fist time I crammed two different point update installers – both relying on a patch that requires a normally hidden partition made visible, at that – from the same major macOS release into a single physical drive.

I know none of this is very practical usability-wise anyway, because of said blessed volume names, but, from a strictly functional point of view, please do enlighten me and tell me if I'm royally screwing up with this weird setup – even by my standards, I should add. At this point, I'd much rather spend the money on a new/extra USB stick (this one in particular, a chunky USB-A 128 GB thumb drive from EMTEC, has brought me a world of pain in the past anyway – I rarely get multiple-partition setups to work properly on it for long, especially when I throw NTFS or exFAT formatting into the mix, which kind of defeats the purpose of having a large universal-ish partition for large data transfers –, so it's not like I would miss functionality that, err, wasn't really there reliably to begin with) and making my USB drive pocket bulkier and heavier still, than having to deal with all these issues.

joaofrgomes commented 3 years ago

Oh, another update: the installer went nowhere after selecting “Install macOS Big Sur” and proceeding (the only utility I could still open was Terminal, and trying to start the installer manually from there also threw some errors about missing frameworks)…

Also, I completely forgot about disabling FileVault in my test SSD, and I also have it enabled it on my internal one (could that also explain why the installer was taking so long to examine the drives?). From what I recall from your Readme file, upgrading from Catalina with FileVault enabled was either impossible or riddled with issues of its own, so, assuming FileVault is very flaky and those issues may also plague point updates, I just swapped the SSDs, booted off of the test one internally and disabled encryption.

Anyhoo, I guess I'll just nuke the entire partition tree on the stupid EMTEC drive and recreate and patch a macOS 11.1 installer from scratch to be extra sure that everything's fine. Wish me luck!