[conspire] (forw) Re: SVBUG

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 21 Sep 2010 18:00:56 -0700
From: Rick Moen <rick at linuxmafia.com>
To: A User <auser at example.com>
Cc: Rick Moen <rick at linuxmafia.com>
Subject: Re: SVBUG
Organization: If you lived here, you'd be $HOME already.

Quoting A User (auser at example.com):

> You indicated that I would be better off with an emulator.  What
> advantages do you see?   My SUSE Linux and Windows 7 projects preclude
> the use of the emulator.

This explanation may be academic if you say something about your
projects preclude use of virtual machines (what you're calling 'the
emulator').  That having been said:


1 of 2.  Consider the usage model for multibooting.  You must have a
bootloader (or, more frequently, a chain of bootloaders -- if only
because every MS-Windows startup I've ever heard of uses Microsoft's
OSloader to launch the NT kernel and hand it its root filesystem).  The
bootloader, or chain of bootloaders, must be able to contend with ROM
setup provided and with the partitioning scheme in use.  Each of the
various OSes must be handed (by the bootloader or bootloaders) a startup
environment it can cope with, e.g., it must not get freaked out by the
nearby presence of foreign-OS filesystems.

To create this situation, typically you must (or are best off doing)
blow away everything on the HD, then do a custom installation of each
OS, then craft a suitable bootloader configuration.  (OS X 10.6.3 and
later include non-destructive resizing for HFS+, so you can finesse the
repartitioning a bit using that or similar tools.)

The ROM setup of new iBooks is of course EFI, and the partitioning
scheme is the corresponding Intel-defined GUID Partition Table (aka GPT)
format.

As you will have noticed, only a limited number of bootloaders can deal
with EFI.  Among those are Grub2, Apple's Boot Camp Assistant (with
related updates to diskutil and Disk Utility to add support for hybrid
GPT/MBR partition tables, synchronising the contents of the GPT and the
emulated 'MBR' table), and elilo (EFI LInux boot LOader),
http://elilo.sourceforge.net/.

rEFIt (http://refit.sourceforge.net/) is an open-source toolkit for
managing EFI machines' multiboot insanity, e.g., controlling the
contents of bootloader menus and definition files.  I believe it also
handles switching from EFI-boot mode to emulation of old-school
IBM/Microsoft BIOS 'MBR' booting (the same trick Boot Camp Assistant
and patched diskutil/Disk Utilities tools do) where useful, e.g., for
the benefit of MS-Windows, which cannot read GPT, last I heard.

Upon startup, you are running a single OS natively -- one at a time,
e.g., just OS X 10.6.3 Snow Leopard, or just Windows 7, or just OpenSUSE
11.3, or OpenBSD 4.7.  On the plus side, that means native-operation
levels of performance, i.e., you get full access to the speed and
functionality capabilities of your hardware without intermediate
software layers to slow you down and in some cases interfere with access
to advanced hardware functions.  On the minus side, any hardware element
(chipset) for which the running OS lacks driver support will not work on
that OS, at all.  Wireless, onboard modems, sound, and 3D video are
frequent areas of problems.

Also on the minus side, inevitably you will find the 'I'm in the wrong
OS' problem much more of a dealbreaker than you probably imagine it will
be.  You will be doing ongoing work in OS X, and suddenly remember
something you want to check out in SUSE -- so, now you have to close all
your files and applications, shut down the OS, reboot, select SUSE, go
through its startup, wait a few more minutes, do your task.  You've had
several minutes of interruption while switching OS, plus you've lost
permanently the state you had running in OS X, and will have to go back
and re-open everything.  This ends up being more disruptive than people
imagine, and, over time, they end up compensating by deferring other-OS
work longer and longer, ending up really almost never using any but a
single OS even though all the others are theoretically available.


2 of 2.  Consider the usage model for virtual machines.  You leave your
primary, original OS intact -- no blowing away, repartitioning,
reinstalling.  You install virtual machine software -- e.g., VMware
Fusion, Parallels, VirtualBox, etc.  Let's say you leave OS X 10.6.3
Snow Leopard as your original, primary OS.  Within the virtual machine
software, you define a VM setup for each other-OS.  The VM presents to
each guest OS a simple boot setup (needn't be EFI), a simple
partitioning setup (needn't be GPT) on a virtual disk hosted in a single
file in the host OS's filesystem, and simple-to-support virtual hardware
presenting no challenges for OS driver support.

On the minus side, this uses significant RAM and CPU, because you are
running multiple OSes at once.  Also, each guest OS cannot run at full
native speed on account of VM overhead, and it's possible that some of
the more advanced capabilities of the hardware will not be fully
exploitable within the guest OS.

On the plus side, the 'I'm in the wrong OS' problem goes away
completely.  You have concurrent functionality inside all the OSes you
care to have simultaneously running.  No waiting, no need to ever shut
down all files and applications just to check out something in a
different OS.



> I have previously run a triple boot with Open BSD, SUSE Linux, and
> Windows XP, and had no problem whatsoever.  Some of my readings
> suggest that there is some added complexity with a quad boot that
> needs to be evaluated.
> Those readings seem to suggest that that Open BSD should not be the
> first thing installed and that Windows should be last
> http://www.anomalousanomaly.com/2008/10/31/triple-booting-your-mac/ --
> at least with a triple boot.
> The same author who wrote this article cited some problems and work
> around situations for a quad boot using Mac OSX, Free BSD, Ubuntu
> Linux, and Windows 7 http://www.anomalousanomaly.com/  My question is
> whether or not Open BSD has the same problems picking up Mac's EFI as
> Free BSD?  I have already verified that SUSE Linux will work with
> GRUB2, that SUSE has legacy GRUB installed, and that GRUB2 is
> available if installation is required.  But do I need it?

FreeBSD has problems not with EFI (because FreeBSD doesn't handle
bootloading; something like GRUB2 does) but rather with GPT partition
maps.  So, you can use the Apple tools and/or rEFIt to hide GPT and
emulate 'MBR' for its benefit.

I would expect that the same trick would work with OpenBSD.  No
guarantees, though.  Quadruple-booting on an EFI/GPT machine makes you
something of a pioneer, and perhaps you know the old joke:  You can tell
the pioneers in computing by the arrows sticking out of their backs.

Disclaimer:  I have no relevant experience with any of this; I just read
about it.  Personally, I work hard to avoid unnecessary complexity in my
boot setups.  The last time I needed multiple OSes was when I was
working as a Linux engineer at a large EDA company and was issued a
current-model ThinkPad as my work machine.  Said firm needed me to
have good native Linux functionality but also relied heavily on
MS-Exchange Server and several rather haplessly ActiveX-dependent
intranet sites for internal communication.  So, I installed VMware
Workstation 5.5, then installed MS-Windows XP Pro inside that, and
thereafter ran MS-Office / MS-Outlook as required inside the VM.
This confined the Microsoft nuisance in a small VM box, but left it
fully functional without delays whenever required.

There are other people in CABAL who are more enthusiastic multibooters,
notably Bruce Coston.  However, doing that with EFI/GPT is what I'd
predict to be still rare.

-- 
Cheers,                English is essentially a language in which "up" has 
Rick Moen              forty-seven dictionary definitions, but 
rick at linuxmafia.com    antidisestablishmentarianism is considered a "hard word."
McQ!  (4x80)           -- John M. Ford, http://ccil.org/~cowan/essential.html

----- End forwarded message -----