Rescue me ... from `grub rescue`?

I can’t seem to bring my vintage MacMini (c. 2011) back to life.

In the past, along with MacOS High Sierra (the last one Apple would support on this hardware), I also had - at various points in time - EOS, Kali, BlackArch, Manjaro up and running on internal hard drive and external hard drives.

But now here’s my situation:

  • Cannot get it to recognize any ISO attempted to load from various thumb drives (EOS, Arch, BlackArch, Manjaro, Kali…). Each one fails at a different early stage of installation and never gets anywhere near the finish line.
  • Similarly, cannot get it to boot up from Ventoy (trying any of the above OSs). It recognizes Ventoy, but won’t install any of the ISOs contained on the USB.
  • Cannot even get Apple to allow me to download a recovery MacOS operating system (High Sierra) for some reason - just gives me a failure message about how that OS is not available.
  • And I cannot even find a drive or partition on which grub rescue can recognize a known filesystem:

Having researched grub rescue a good bit, if I could find one of those previously installed Linux partitions out there I could probably raise this MacMini from the ashes accordingly.

But if none of these partitions listed in ls has a recognizable filesystem, and when I boot up holding the option key I cannot recover a functional High Sierra MacOS instance or boot from any USB-based ISO image, how might I breath life back into this otherwise fine piece of hardware? :thinking:

Wild guess. Shouldn’t command be ls (hd0)/ ? See the slash.

Also without installation specific errors, hard to understand what is happening. But from your description implies that installation starts.

1 Like

Thank you for offering up this idea. I thought I had gone through that approach previously (since some grub rescue instructions include the slash, and some don;t), but to be sure I checked again just in case…

As I’d recalled: the / slashes don’t make a difference in the system being unable to identify any known filesystem.

I do appreciate that error messages could be quite helpful in sleuthing the problem. Unfortunately, for the most part there are no error messages … just a lock up or blank screen upon attempting to boot up from various ISO thumb drives using any distro I’ve tried thus far.

With one exception: The Arch ISO makes some progress but doesn’t get too far. Here’s what I get, each screenful in succession (BTW, the screen doesn’t look dusty at all in real life!):

… and that final screen repeats every 10 seconds with successive “timeout” errors and no further progress.

Does any of this info help narrow down the challenge?

Sir, I started to Google your issue, and then encountered question which you already asked here:
Cannot install - but perhaps more of an Arch issue than EOS? - #10 by UncleSpellbinder with same errors :confused:

If you cannot boot from live USB, and you used to be able in the past, seems like a hardware issue :frowning: Especially what fails is this: https://manpages.ubuntu.com/manpages/focal/en/man4/sdhci.4freebsd.html

IDK much about Apple, but in theory you could open your Mac, disconnect hard disk and try again to boot from Live USB - could exclude disk failure. At the same time you could check all connections inside. Also reconnect RAM as well, or try only with one stick.

Anyway, seems like this question should now be asked in some Apple forum at this point, how to diagnose hardware issue.

1 Like

Yeah, I’ve been trying to resurrect this thing going back well into 2023. Every few months I try again - start over - hit a wall - put it aside … forget about it.

Then try again - hoping something magical has changed.

So far, it hasn’t.

I’ve googled this thing to death myself and none of the possibilities I’ve found seems to solve it. Apple forums included.

I keep hoping someone out there knows something that no one else seems to know to cure this issue. Alas.

Thanks for taking time in an effort to help! :pray:

If you insist on going more deep software way: get https://www.system-rescue.org/ and see how far it will take you. Do some tests. Try some options. Etc.

If will not help, start tearing this thing down. Telling you, looks like a hardware issue: hardware cmd interrupt (I assume you tried different USB sticks, right?)

1 Like

This looks like a promising path to follow. Thanks for the link. I’ll report back if I can detect signs of life. :vulcan_salute:

Sure, just report in this thread, or even the previous one. No need to create new ones.

1 Like

Try resetting NVRAM or PRAM first, to see if it makes a difference.

1 Like

@ejm
Did you updated ventoy if that is what you are using?

Thanks for this suggestion. I thought I’d tried this maneuver months ago in a previous attempt, but to be sure I just tried it again… unfortunately, not making a difference in the outcome. :cry:

Yes, sir. Using the latest version of ventoy-bin 1.0.99-1 :man_shrugging:
(Also tried each ISO directly in isolation without ventoy involvement with same results.)

Do you still have Mac OSX on it?

Actually, that’s an interesting question…

Last time this MacMini was functional, it had a High Sierra MacOS partition that was operational. But for many months now I have been unable to get the MacMini to boot up in MacOS, either.

I’ve also tried all of the many Apple OS recovery avenues I could find. When I seemingly get connected to recover the MacOS from Apple’s site, after a while it fails to finish - saying (something to the effect that) this OS is not available.

I figure if I can get any OS of any type up and running, from there I could leapfrog to my desired goal: EOS.

Still plugging away as of this writing…will share any meaningful updates in case someone else lands in similar footsteps. :roll_eyes:

Is this one of the Mac’s that uses a 32 bit boot process? I’ve never owned any Mac hardware so I’m not much help. :wink:

Hmmm… another interesting thought. So I googled around to see what I could find and cannot determine the answer. My recollection is that this was a 64 bit machine from the get-go.

If it’s any consolation, I’ve owned lots of Mac hardware … and I not much help either :laughing:

1 Like

FINAL UPDATE - WILL MARK THIS AS SOLVED (…for the benefit of anyone else searching for solution to similar Apple legacy hardware issues):

1 - Suspecting that perhaps my ISO media were the problems, I tried these SD cards (containing EOS ISO, Ventoy w/ EOS and other ISOs) on other vintage Apple hardware (i.e., 2011 MBP laptop and 2019 iMac which are currently running EOS perfectly) and I faced the same sdhci: ADMA err seen above. They wouldn’t boot up from the SD card ISOs either.

And yet, these same SD cards booted up nicely on an old Dell Optiplex… Aha!

So I surmise that these legacy Apple boxes, at least in their native state, can’t use their built-in SD card slots for ISO bootup purposes.

Next, I burned these same ISO images onto USB thumbdrives instead of SD cards. I had tried USB thumbdrives months ago and failed to get far, but perhaps I was using an older version of Ventoy then?

2 - Although I can’t be sure which combination of the following steps provided the critical solution, but taken together it worked…

  • I made sure I was using the latest Ventoy and balena-etcher
  • I then booted into Systemrescue to access gparted and created a fresh ext4 partition on the HDD.
  • I then used the latest Ventoy to boot up into the latest EOS ISO (using Grub 2 selection).
  • Having successfully booted into the EOS live USB, I immediately installed EOS/i3 to that fresh ext4 partition using my web-based household wifi connection.

And so, EOS/i3-wm is now installed on a HDD partition of this vintage MacMini. As far as this thread is concerned, case closed!

- - - - - - - - - - - - - - -

Since my current challenges are not directly relevant to this thread I have closed this out and, if necessary, create fresh posts on those.

FYI, although both my ethernet and wifi worked fine while installing EOS, when I now start up EOS, I cannot get NetworkManager to connect with either ethernet cable or wifi while NetworkManager explicitly lists both access points, but as “never” having been used. :thinking:.

Meanwhile, inxi shows the Broadcom driver as being installed but “down” while systemctl shows that NetworkManager is active and running :man_shrugging:

BTW, I haven’t managed to get this newly-installed EOS installation to boot up without using Systemrescue to “find Linux root” each time I power up, but I’ll deal with this separately, try to solve by editing fstab etc.

Meanwhile, many thanks again to those who offered thoughtful help above.

My current remaining challenges are all likely solvable with additional time and effort of a different kind. :vulcan_salute:

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.