Re: debian installation issue

[David Wright <deblis@lionunicorn.co.uk>]

On Tue 29 Jun 2021 at 13:26:04 (-0400), Felix Miata wrote:
> David Wright composed on 2021-06-29 11:16 (UTC-0500):
> > On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote:
> >> David Wright composed on 2021-06-22 10:50 (UTC-0500):
> 
> >> I'm not sure there is "a" definition. One could be any code that a Windows
> >> installation would not replace. Another could be based on what it does:
> 
> >> 1-locate a legal boot flag
> >> 2-load an appropriate sector pointed to by a legal flag
> >> 3-announce error if the above conditions are not met
> 
> >> A legal flag is any flag on a primary partition on a disk on which no other boot
> >> flags are present in the MBR table.
> 
> > I don't understand the attraction of messing about with boot flags
> > in order to choose which primary partition to boot from. It seems
> > inelegant to write to the drive just for that.
> 
> 1-It's Windows compatible. With it, Windows 7/10 won't refuse to complete updates
> when it doesn't find something it expects in the partition table. "Refuse" in this
> case means install a big heap of updates, then decide it can't finish, and wastes
> more time uninstalling those it just installed, followed by announcing there are a
> heap of updates to install, repeat ad nauseum.

I haven't met that problem. I've run W10 on UEFI with stretch and
buster on BIOS-MBR using Grub, and the two OSes were effectively
unaware of each other. (I can't speak to W7, as that had been upgraded
by the time I started using the machine.

> 2-The system was invented over 4 decades ago, before the PC compatible HD
> partitioning system was upgraded to allow for more than 4 partitions per HD.

Sorry, what system?

> 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly
> openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not enabled), on
> all MBR systems,

I'm not sure of the relevance of the Grub version, but I assume, from
your previous post, that Grub is installed in individual partitions,
not in the MBR/"on the disk".

OK, yes, I can see that you have a reason, apparently, to keep Grub
away from the MBR on the systems where there's a sensitive Windows
installation, but for someone like the OP, coming to a linux system
afresh, I can't see any reason for them to add complexity by not
installing Grub on the MBR (assuming BIOS booting is in force).

> and Grub2-efi on UEFI systems, including Intel Mac.
> 
> >> > Are there OSes that would install it themselves to a new blank disk?
>  	
> >> One version would be code a Windows installation would put there.
> 
> >> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK
> >> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot.
> 
> >> I would expect the FreeDOS version of FDISK or its installer to do the same.
> 
> >> I normally use code derived from OS/2, installed by DFSee when I first partition a
> >> disk.
> 
> > Obtaining DFSee might be alright for someone invested in MBR booting,
> > but for most people, MBR is obsolescent. Putting Grub on the MBR can
> > give a user interface more similar to current machines that use Grub
> > on UEFI, which seems an advantage.
> 	
> UEFI is an incontrovertible improvement over MBR, but MBR will be around quite a
> while yet for machines that don't include UEFI.
> 
> DFSee isn't a mere partitioner, and is not for MBR systems only. Among other
> features, it's also a copier/cloner, a binary editor of files and raw sectors, can
> be scripted, and it logs in plain text. Its logs are an indispensable part of my
> environment, facilitating inventorying several hundred partitions and operating
> systems spread across tens of uniquely partitioned and OS-equipped multiboot
> machines. It includes free personal support from its author, as well as a helpful
> support mailing list. It's interface is identical whether run from DOS, Linux,
> Mac, OS/2 or Windows.

Yes, you've posted inventories listed with that tool in the past
(I have one here, for ST HP GB0500…) and that's what I meant by being
"invested in". But again, it's just extra complexity for most people.
Don't misunderstand me, I'm not criticising your individual approach,
but I can't find any more religion in Greg's (qualified) remark than
in your views expressed about Grub/Grub2 and MBRs. I see them both
as strong preferences, held for good reasons.

Cheers,
David.