[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] [grub-installer] Drop workaround for Intel-based Macs





Hello Adrian.

I am not sure when exactly this problem was fixed.

But I found that a workaround appeared sometime in 2006, along with a recommendation to use elilo instead of grub. The commit is here:
https://salsa.debian.org/installer-team/grub-installer/-/commit/9bc15147affeb12a9d9fe58f7d7871a54ecf5d98


Since then, elilo has disappeared and grub2 has come along and evolved for almost 20 years. It is now the only option in the Debian installer.


I think the workaround was originally introduced because of GRUB1's incompatibility with the UEFI of Intel-based Macs. Frankly, I was a bit surprised when the Debian installer prompted me to skip the bootloader installation and load the kernel manually. There was no option to install the bootloader at all during the installation process.

Anyway, I tested installing Debian 12 on a Macbook A1342 (mid2010) without avoiding GRUB/EFI installation. GRUB2 installed automatically during the installation and everything works just fine!

--
Best regards,
Arthur D.


> Hi Arthur,
> > On Wed, 2025-04-30 at 07:10 +0300, Arthur Demchenkov wrote:
> > It works fine now
> > ---
> >  debian/isinstallable | 5 -----
> >  1 file changed, 5 deletions(-)
> > > > diff --git a/debian/isinstallable b/debian/isinstallable
> > index af53d782..c869b7e4 100755
> > --- a/debian/isinstallable
> > +++ b/debian/isinstallable
> > @@ -9,11 +9,6 @@ ARCH="$(archdetect)"
> > > > case $ARCH in
> >      i386/mac|amd64/mac)
> > -	# Note: depends on partman-efi to load the efivars module!
> > -	if [ -d /sys/firmware/efi ]; then
> > -		log "GRUB not yet usable on Intel-based Macs booted using EFI"
> > -		exit 1
> > -	fi
> >  	;;
> >      mipsel/loongson-2f)
> >  	;;
> > Thanks a lot for your patch! Could you elaborate on this a little more? > > When was this particular issue fixed. Was this a fix in GRUB upstream? > > I would prefer this to be better documented so we're clear whether there
> might be setups where this workaround may still be required or not.
> > Thanks,
> Adrian


Reply to: