CentOS - Jul 2015 - dual-booting <- Re: installing Cents os server 7.0

On Thu, Jul 2, 2015 at 6:22 PM, Warren Young <wyml at etr-usa.com>
wrote:
> On Jul 2, 2015, at 5:33 PM, Chris Murphy <lists at colorremedies.com>
wrote:
>>
>> On Thu, Jul 2, 2015 at 4:12 PM, Warren Young <wyml at
etr-usa.com> wrote:
>>> On Jul 2, 2015, at 11:32 AM, Chris Murphy <lists at
colorremedies.com> wrote:
>>>>
>>>> It's effectively impossible. Very few people know how to do
this.
>>>
>>> Relatively few people know how to write C programs, but that
doesn?t make it "effectively impossible? to write them, nor does it mean
that CentOS can?t run C programs.
>>
>> Bad analogy. Car doesn't come with a CD player. Does the dealer
>> support your user installed CD player? No. Your CD player, you
>> installed it, you support it, or whoever you paid to install it can
>> support it, not the car manufacturer or dealer's problem.
>
> Car analogies are almost as bad as philosophy when it comes to getting
oneself tangled in thought.
>
> The ?CD player? equivalent of the current CentOS situation is the old DIN
7736 standard: https://en.wikipedia.org/wiki/ISO_7736
>
> If your car has a DIN 7736 bay, you can easily replace the existing head
unit without redesigning the car.  This is directly equivalent to repartitioning
and installing CentOS alongside Windows.
OK? 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. Just like the car dealer doesn't support this new head
unit I installed, because I installed it.


> If you have UEFI and Secure Boot screwing things up for you, that?s like
one of these modern cars that integrates the body computer and what we used to
call the head unit into a single proprietary electronics package so that if you
tried to replace the radio, you could no longer roll down the windows.
Bad analogy, you clearly don't understand the purpose of Secure Boot,
or you've subscribed to some distorting philosophy.

I should not have to use proprietary software to be reasonably assured
I'm not inadvertently owned by boot loader malware. So yes, free
software absolutely must support UEFI Secure Boot properly. And, by
the way, openSUSE has done this correctly for ~3 years. It's
RH/CentOS/Fedora's GRUB that doesn't have these patches, I've
already
cited that bug. It's like you're willfully ignoring the facts and just
making up regurgitated Secure Boot nonsense.


>
> To blame CentOS for this UEFI+SB situation is like blaming Crutchfield for
the fact that you can?t buy a Pioneer head unit for a 2015 Ford Focus.  In both
cases, the blame properly resides with the provider of the host hardware.
This is wrong. And it's dangerous for any user to believe it. You
would have users subscribe to "big sky theory" when it comes to root
kits, and just hope to some deity that they never get such a thing.
It's the good old plain luck method of computer security.




>
>>>> Fewer care to learn when there are platforms that make this
much
>>>> easier.
>>>
>>> If you want Ubuntu, you know where to get it.
>>
>> Ubuntu fails to boot UEFI+Secure Boot Windows 8.x as well. For some
>> lame reason, only openSUSE has the secure boot patches for GRUB
>
> Whatever.  Unimportant detail.
>
> The important thing is that the availability of OSes that do this does not
force CentOS to also do it.
I never said it did. I said it's embarassing that it doesn't.


>
> Regardless, this is not the right place to argue about it.  CentOS does not
drive changes into Fedora or RHEL.  If you want this fixed, get involved with
Fedora.
I included URLs for the bugs I either filed or have contributed to in
trying to get this problems solved *on Fedora*.
>
>> Android arrived at rapid success
>
> Yyyeahh?  A bit of revisionist history there.
>
> Android started out in 2003 as yet another boring cellphone OS, aimed at
replacing the likes of Palm, Symbian, Blackberry, and Danger.  Google bought
them in 2005, but the resulting Android 1.0 utterly failed to set the world on
fire.
>
> It wasn?t until 2007 when the iPhone came out and showed the world what a
mobile communication device was supposed to look like that Google got onto the
path that lead to what we think of as Android today.
>
> Android 2.x (2009) was Google?s first try at market space exclusively held
by the iPhone, up to that time.  It was to iPhone as Ubuntu is to OS X today:
kinda the same thing, but not really a serious competitor.
>
> Then they rebuilt much of the OS in the semi-proprietary 3.x line, which
wasn?t widely deployed to the rest of the OHA partners until 4.0 came out in
2011.
>
> That?s between 4 and 8 years to achieve ?rapid success,? and it was done
with the resources of a $133+ bn company chasing a 2+ bn handset market.
>
> The idea that CentOS can or even should follow such a trajectory is
ridiculous.
No I'd be better off comparing it to Windows or OS X. Desktop vs
desktop, rather than desktop vs mobile. The reason why I compared to
Android is because it is Linux based and a lot of it is free software.
So that 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.
> Oh, and just to drag this thing back on-point, Android won?t repartition an
iOS device and dual-boot *it*, either.
Nope, it's not a supported configuration. The user can do that,
therefore it's user supported. But it's also a fairly obscure use
case, so I don't expect it to be easy. There are a lot of people dual
booting who don't understand how it works, or  how to make it work or
how to fix it. And that is why I say it needs better support. It's for
those users I advocate it. Otherwise, they use a Mac - which just so
happens to have this so totally figured out they've put a GUI boot
manager into the firmware, so it doesn't really matter (other than
ugliness) that GRUB's OS X menu entries kernel panic the system.



>
>> And no it's not just about dual boot. It's also the never
ending
>> regressions that break things.
>
> Welcome to computing.
>
> There is no shielded enclave where nothing changes, and nothing breaks.
Apple's installer. Nothing changes. Nothing's broken. Windows
installer? Nothing changes. Nothing's broken.

Aanconda? Constant changes, and give me 5 minutes and I guarantee  you
I will find a bug worth filing a report for (in addition to the ~
hundred I've already filed). Anacona is like the great city of New
York. It's bad ass. But it's never finished, and something's always
broken.


-- 
Chris Murphy

On Jul 2, 2015, at 9:21 PM, Chris Murphy <lists at 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.

That counts as ?supports dual boot? in my book.

I do not require that CentOS be able to *create* that free space.  That?s my
job.
> Just like the car dealer doesn't support this new head
> unit I installed, because I installed it.
If you buy a car from a dealer and it has an open DIN bay, you can install your
own head unit into it.

This is exactly analogous to booting the CentOS installer with free space on a
second drive or an unused partition.

Just because most cars come off the lot with something plugging that space up
doesn?t mean it?s Crutchfield?s problem to fix, any more than it?s CentOS?s
problem to fix UEFI+SB on your new Dell.

Once again: It would indeed be *nice* if CentOS could resize an NTFS partition
to make room for itself, despite UEFI+SB.  My problem is only with your
insistence that it *must* do this.
>> Regardless, this is not the right place to argue about it.  CentOS does
not drive changes into Fedora or RHEL.  If you want this fixed, get involved
with Fedora.
> 
> I included URLs for the bugs I either filed or have contributed to in
> trying to get this problems solved *on Fedora*.
So why are you continuing to bang on about it on a CentOS mailing list?  No
amount of yelling here will change anything.  Take it to where you can effect
change.

I will expect to see the results of your efforts when CentOS 8 comes out, years
hence.
>> The idea that CentOS can or even should follow such a trajectory is
ridiculous.
> 
> No I'd be better off comparing it to Windows or OS X.
Neither Windows nor OS X will nondestructively push aside a competing OS?s
installation to make room for itself to dual-boot.
> The reason why I compared to
> Android is because it is Linux based and a lot of it is free software.
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.
> 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?
> ...they use a Mac - which just so
> happens to have this so totally figured out they've put a GUI boot
> manager into the firmware
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.

Windows likewise won?t push OS X aside on Apple hardware.  It requires Boot
Camp?s help to do that, which is a nice tool, but you?re arguing against using
third-party utilities.  (Boot Camp being third-party with respect to Windows.)

You?re asking CentOS to *exceed* what Apple, Microsoft, and Google do without
giving it any of their market advantages first.
>> 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.

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.
> 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.

Go try to run No One Lives Forever on Windows 8, and tell me nothing breaks.

And this despite Microsoft?s heroic levels of backwards-compatibility, fueled by
$173 billion in assets, which allows it to employ 128,000 people.

But CentOS must meet this same level.

Y?right!

On Thu, Jul 2, 2015, 11:05 PM Warren Young <wyml at etr-usa.com> wrote:

>
> On Jul 2, 2015, at 9:21 PM, Chris Murphy <lists at 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