On Thu, Jul 2, 2015, 11:05 PM Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 9:21 PM, Chris Murphy lists@colorremedies.com wrote:
CentOS doesn't support dual boot, because I did all the work to make that happen, the CentOS installer did nothing to help me make this possible.
If free space on a drive is available at time of installation, CentOS
will let you install itself into it, and it will even offer to put its boot loader on a CentOS partition instead of overwriting the boot drive’s boot sector.
The CentOS 7 installer does not support installing GRUB to a partition. It can be installed, or not. If installed it goes in the MBR gap, or the BIOSboot partition, or EFI System partition.
And because there's no ntfsprogs, grub2-mkconfig won't find Windows and won't create a menu entry for it.
That counts as “supports dual boot” in my book.
Supporting dual boot means ability to boot both installed OS's upon completion of installing the second. This doesn't happen when the first OS is Linux using LVM, or Windows, or OS X.
Merely installing into free space constituting dual boot support means anything and everything supports dual boot to the point the term is meaningless.
I do not require that CentOS be able to *create* that free space. That’s
my job.
You have more jobs to do than that post-install to actually get it to dual boot. The operative word is boot.
Android only installs single-boot on hardware made specifically for it.
It can make up whatever rules it likes for that hardware.
You’re trying to extend that to CentOS pushing Windows aside on a machine
that came from the factory running Windows. It’s a specious argument.
No I'm saying it does a better job doing what most of its users want it to do rather than requiring them to knows esoteric things. It's not meant to be an dual boot comparison.
And it's established that Cent OS does not push Windows aside. You have to do that outside the CentOS installer.
Android managed to get where it is today has to do with what's made all of these things more successful than Linux on the desktop and that's simply better user experience.
Until you explain how you’re going to get CentOS to be preinstalled on a
billion devices per year, I don’t see how you can connect Android’s success to CentOS. Where is the market force that will cause this to happen?
I'm not making a number of installs argument. I'm talking about user experience.
For the significant minority who need dual boot, they are not at all well served by these distros. Only Fedora really supports it, and only with Windows, and only if Secure Boot isn't enabled.
While I will agree that holding Option or C down on boot is worlds better
than madly pressing DEL and then poking around in a BIOS/EFI screen to switch around the boot order, I don’t really see what this has to do with the question at hand. OS X’s installer won’t push a Windows installation aside and make room for itself to dual-boot, either.
Correct. It does not support installing after Windows. Its dual boot support is only supported when installing after Windows.
Of course it can be done with CLI tools by the user. But this isn't an Apple supported configuration.
You’re asking CentOS to *exceed* what Apple, Microsoft, and Google do
without giving it any of their market advantages first.
I'm asking that the CentOS installer not break bootability of the first installed OS. And that to be "supporting dual boot" that two OS's can in fact be booted upon completion of the installation.
NTFS shrink is icing. It's not the main requirement.
There is no shielded enclave where nothing changes, and nothing breaks.
Apple's installer. Nothing changes. Nothing's broken.
Apple breaks stuff *all* *the* *time*. They’re famous for it.
Not their installer. It's pretty much the same since ancient times. If anything it now has fewer features.
And I’m telling you this as an Apple fanboi. I have accepted the fact
that I must cope with broken stuff on my Macs, just as I do on my CentOS boxen.
OS X 10.n only on the computer. Then shrink that volume, and make a second volume, and install 10.n+1. Both boot. Out of the box. No post install work. Same for Windows.
RHEL/CentOS/Fedora? N and then N+1? N will fail to boot until you fix it post install. And grub2-mkconfig won't help do it correctly in a way that obviates having to always manually run it again.
Terrible UX.
Windows installer? Nothing changes. Nothing's broken.
Go compare the standard paths for changing network settings in Windows
2000, XP, Vista, 7, 8, and 10, and tell me Microsoft never moves things around.
Installer. You said there is no shielded enclave. All I had to do to prove that wrong was provide one example. I provided two.
But at least you let the Secure Boot arguing go...
Chris Murphy