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

Re: installing NETINST 20190127 on Mac mini G4



On 1/28/19 1:52 PM, Frank Scheiner wrote:
> @Rick:
> I thought about something like this since Mark reported the bootstrap
> limits in OpenBIOS. It could in principle work similar to the switch
> between non-GPT and GPT capable SPARC hardware ([1]).

I don't understand this argument. GRUB works on PowerPC Macs and is
fully supported or am I missing something? I also works fine on SPARC
hardware with Sun partition tables.

Unless you want to install on very old SPARC hardware, there is no
need to carry SILO around. Our tests have shown that GRUB works on
any 64-bit SPARC hardware which means that anything going back to
the mid-90ies is supported.

> [1]:
> https://salsa.debian.org/installer-team/grub-installer/commit/8cd8db89cb1fdd554f153ec6af74d8a30c05a3be
> 
> But as long as nobody is maintaining the software this is meant to
> support (i.e. yaboot and all the HFS related stuff), I don't think a
> development effort is justified. Sorry. :-/

Yaboot would probably require extensive development work to get it
going again.

>> Why do you think should the installer support a boot loader that is known
>> to be buggy and unmaintained? If users insist on using Yaboot, they can
>> still install it manually. I do not see a point, however, to keep it in
>> the archive.
> 
> @Adrian:
> Did you perhaps meant to write "I do not see a point, however, to
> **not** keep it in the archive."? It would be unsupported though, but
> users could still use yaboot and help out each other with tips and
> tricks in case of problems.

No, I meant that I don't see a point in keeping it. It's buggy and
unmaintained and even requires old and unsupported ext2 development
headers to be able to build it.

If we keep it and allow users to use it, it will lead to people installing
and running into these bugs with potential data loss.

> Apart from the issues with "legacy" bootloaders like yaboot and SILO, I
> find it still useful to have another bootloader available for
> verification, e.g. in cases where bootloader A makes problems and the
> verification on another bootloader B could show if this is a general
> problem or a problem with bootloader A only.

The problem with keeping the alternative, unmaintained bootloaders in
the archive is that users will use and install them and cause additional
support requests on the mailing lists.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Reply to: