Installing macOS on a new, blank disk

Dear Lazyweb,

I've got this stack of old Minis that I'm trying to rehabilitate by putting cheap SSDs in them. (I've got some time on my hands, and it beats them becoming landfill.)

I've done this several times before, and mostly it has been going according to plan, but I've got this Mid-2011 i5 that I just can't figure out. I can boot it off an external disk that is running 10.13.6 (the latest OS that this hardware can run) but nothing I try -- booting the recovery partition from the external drive, booting internet recovery from BIOS, or running the "Install macOS High Sierra" app when booted off of the external drive -- leaves me with a bootable system on the new, internal SSD.

It never updates the new disk's partition table to have an "Apple_Boot Recovery HD" partition on it, which is probably not a good sign, but beyond that, it's never able to boot the second phase of the installer. "/macOS Install Data/" exists on the new drive, but it panics with "error loading kernel cache".

If I rsync the contents of the external disk onto the new internal SSD, I can boot off the SSD -- but only while the external disk is plugged in.

Any ideas?

Previously.

Tags: , ,

27 Responses:

  1. Phil says:

    I have no direct experience, but if I faced this issue I might try to use rEFInd to intercept the boot process. My guess is that there is some firmware/timing bug related to the startup of the SSD where something is happening too fast or too slow, and inserting a boot manager might disrupt that dynamic.

    I presume you already tried a different model of SSD or a firmware update of that SSD.

    • jwz says:

      No, but I've used this same model of SSD in several other Macs.

      It smells like some kind of boot record is missing from the new disk.

  2. Scott says:

    weird nvram boot args from a previous life? reset nvram?

  3. Liam says:

    I would first make sure that it is partitioned with GUID partition map, and the then formatted. I don't think it will boot on that age mac if it's got APM partitioning. It that's already OK, then I would pull the SSD from that machine and install the OS on another Mac (should be OK installed with it in an external case). If it boots that machine your SSD and install is good. I would then try to boot with the SSD in an external case on the problematic mac, and finally test it internally.

  4. Nibby says:

    Hmmm. If you rsync'd the -whole- drive, including the partition map and all partitions, and it boots with the same drive plugged in, but not without, that would seem to indicate that the "ROM" has problems with the new drive, but is cool with external drives. Maybe a workaround would be leaving a bootable thumb drive in it, with just the right magic parts of the external drive on it. Trying to update firmware, that it doesn't do automatically, seems like trouble. Either that or try booting off earlier media (10.6 or something), and see if that helps, and if so work your way up. My experience is "One does not simply boot into 10.13".

    • Nibby says:

      On second thought, maybe the installer just doesn't know what fiddly driver bits (let alone the dang recovery junk) to put on the new fangled SSD-a-majig, which of course should just look like some sata thing but fails some assumption.

  5. phuzz says:

    How about pulling the drive out of one of the working Minis, and trying it in the suspect one?
    I'm guessing you've already checked for any physical damage or problems in the suspect Mini.

  6. ducksauz says:

    Maybe try using SuperDuper! to image one of the working drives to the problematic one? While it's essentially rsync, it does know about all the fiddly bits of making mac drives bootable and such. The free version should do what you need for full disk imaging. You only need to purchase it if you want to incrementals and such.

    • jwz says:

      The working physical drive is larger than the SSD, so I doubt that's gonna work. (Even though the physical drive is far from full.)

      • Dara says:

        Yeah, it won't. The second copy of the GUID partition table will get fucked up and nobody will deal well, including (g)parted which will say it can fix it but WOW it can't fix it.

  7. dzm says:

    I can't say I've tackled this specific problem, but I have done pretty close.

    Generally if I want to start from a completely blank slate I'll boot the machine into "Network Rescue Mode" while plugged into ethernet ('cause WiFi will just make you angrier) (https://support.apple.com/en-us/HT201314, Option-Command-R). This will force the machine to download a copy of whatever the version of macOS was when the machine shipped, then boot into it. I then use DiskUtility to properly format the new SSD, then let the installer have its way with the disk. Once installed and booted I then go through whatever App Store and/or System prefs dance I need to to get updated to the latest version of macOS that this machine will run.

    If I've got a reference disk that works (say, the original drive), and I've got USb ports and adapters available, then I'll use the brew distribution of ddrescue to just make a clean mirror of the old drive. I'll then use DiskUtility to adjust partition sizes (if needed), etc. This solution, of course, presumes the new disk is equal or larger in size to the original.

    Note that the ddrescue methos was used about six months ago to drop a new SSD into a 2012 vintage Mac Mini, so from personal experience I know it works.

    • jwz says:

      Yeah, that's the second thing I tried. Network Rescue downloads and installs phase one of the OS installer, but does not create a recovery partition and does not result in a bootable disk.

  8. jwz says:

    So it turns out that Carbon Copy Cloner knows how to create recovery partitions, copied from one disk to another. So now my SSD has the correct partition layout. That's something. But it still won't boot, even after I reinstall the OS by either rsync or the external disk's Recovery Mode.

    I feel like the Recovery HD partition is a red herring and the real problem is that something else on this disk, either the main file-system partition or something else, is not marked as "bootable" in some way. But I have no idea how the actual Mac boot process works.

    • dzm says:

      First thought: Bad drive?

      Second thought: Have you tried using ddrescue (I really have had good luck with it) to just copy one of the already successfully created drive over this drive? Copying the entire block device, not a file-system rsync copy?

      After that idea I'm getting into increasingly speculative, I-haven't-done-it-here territory so will stop.

      • jwz says:

        I don't see how it can be a bad drive, or bad hardware, or incompatible drive and hardware, when I have managed to install the OS onto the drive and boot it.

        The catch is that the external drive has to do the booting. But after that, the machine runs just fine off the new, internal SSD.

        Copying the entire block device won't work because the old spinning drive and the new SSD are not the same exact size.

      • jwz says:

        And also macOS apparently won't let you dd from the root partition's device, even in standalone boot, when it's mounted read-only. So that's fun.

        • dzm says:

          Yeah, I probably should have provided more context there:

          1) Why ddrescue instead of dd? ddrescue has better error detection and retry in case it hits a bad sector (it was ostensibly designed for trying to copy a failing storage device to a non-failing one by not blocking on bad reads and immediately skipping forward to hopefully copy good blocks before causing a device to finally fail altogether). I realize most of that doesn't really matter in this case. I mostly like it because it has actual feedback to the user on progress and can resume where it left off if you use the "log" option and, for whatever reason, the job gets interrupted. I like feedback. dd is not good at feedback.

          2) The source device should not be mounted, but the OS should be aware of it. I don't recall why I nerd-raged an unmount, but I did end up using diskutil unmount to unmount the volumes but not actually eject them from the system.

          3) I generally ended up with some kludge involving booting off a USB thumb drive, and the Source and Destination disks attached via whatever interfaces were available (generally the internal SATA interface and an external USB3<->SATA adapter).

    • jwz says:

      Wow, that says "This software is not supported on your system" but I think what it's trying to say is, "You can't install MM51.0077.10 because you already have MM51.0080.B00".

  9. jwz says:

    I got it working! I took the new SSD and plugged it into a different Mini (a Late-2012 instead of a Mid-2011) and it immediately ran the phase 2 of the installer that was already there, and booted. Then when I put that disk back in the Mid-2011, it still worked.

    So something about the Mid-2011 just didn't want to make the drive bootable, but once the other machine accomplished that, it was fine.

    Weird.

    • dzM says:

      “Fucking Apple”

    • neek78 says:

      I realise that I'm late to the party here, but the bless(8) command was essential in telling the boot loader where the core system stuff was.

      I remember needing this when moving a system between drives at a file level (ie copy all the files, and then bless the system folder). Not 100% sure how the boot loader itself got on the drive in that case (i have a feeling Disk Utility just put it on there at some point)

  10. Nick Gully says:

    I had a heck of a time getting a 2008 macbook to install. I had let the bootloader update the onboard time, and it resulted in screwing up the Lion installer, due to expired certificates in the installer. I recommend looking at clearing out the date to about when these would have first been setup.

  11. Christopher says:

    FWIW, there's something called Catalina Patcher that enables installing 10.15 on older systems, but I haven't use that.

  • Previously