[CentOS] dual-booting <- Re: installing Cents os server 7.0

Fri Jul 3 03:21:42 UTC 2015
Chris Murphy <lists at colorremedies.com>

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

Chris Murphy