[conspire] (forw) Re: SVBUG

Tue Sep 21 19:25:40 PDT 2010

And, the answer to his question is...

:r! cal

   September 2010   
Su Mo Tu We Th Fr Sa
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30      

...our next meeting is this Saturday, September 25, 2010, 4 PM to
midnight.

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

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

Quoting A User (auser at example.com):

> Thanks for the information.  I have heard bad things about GRUB2.

I wouldn't doubt it.  I don't really trust the damned thing, consider it
suspiciously overengineered, and am a bit ticked off that my Debian
server automatically transitioned from GRUB to GRUB2 when I upgraded it
to (once more) track the Debian-testing branch as is my usual policy.

For that particular application, I'm seriously considering
re-implementing LILO.  (Not an option for EFI/GPT, though elilo is such
an option, and is very closely related to lilo.)

> It is an Alpha and at least 12-18 months away from being anything
> less than real bugware.  One person suggested that I explore the
> possibility of backing up the windows boot loader and installing
> Linux last.  Usually windows must be installed last because it will
> rewrite the masterboot record.

That is correct.  Whenever you install MS-Windows, it presumes to
overwrite whatever it thinks is the MBR program area on the primary boot
drive, and it also sets the MBR partition table's 'Active' flag on
whatever it thinks is the 'C:' drive for MS-Windows, and un-sets the 
Active flag if you've set it on any of the other partitions.

That's because Microsoft Corporation implicitly assume they have the
right to own your hard drive, and cannot bother getting along well with
others.

> However, Linux will allow you to bypass this problem if you know what
> you are doing, and I don't profess to have such knowlege.

Yes.  You do either one of two things:

(1) Concede partial control over the MBR to Microsoft's installer.  Let
it overwrite the MBR program area whenever it wants.  The tiny 446-byte
program it puts there is dumb but reasonably useful.  After it's done,
use a maintenance CD to re-adjust where the Active flag is set, to put
the Active flag where you want it, rather than where Microsoft
Corporation do.  (I've just been in New Zealand and Australia, so I'm
back to referring to corporations as plural nouns, the way most of the
world's English speakers do.  I'm sure you can cope.)

(2) Permit the MS-Windows installer to perform its occasional mayhem,
but then use a maintenance CD to overwrite the MBR program area again to
suit your preference, and as required re-set Active flags.

In case it isn't clear, situation #1 is any situation like the
following.  (For simplicity's sake, I'll talk about a 'MBR' setup, 
without the added complications of adding EFI and GPT.)  You have:

/dev/sda  MBR (This is 446 bytes for initial boot program, 16 bytes
               for a partition table, 2 normally unused bytes at end)
/dev/sda1 NTFS primary partition.  Where MS-Windows lives.
/dev/sda2 ext3 primary partition.  Active flag.  Linux lives here.
/dev/sda3 Linux swap primary partition

In this model, it's OK for the 446-bytes MBR program area to have
Microsoft's first-stage bootloader in it, or get overwritten by it,
because it does what you want done:  It branches control to the first
primary partition bearing the 'Active' flag.  You install your
second-stage bootloader into the boot sector of /dev/sda2, which
Microsoft do _not_ overwrite.  Thereafter, all you have to do is 
reset which primary partition has the Active flag whenever Microsoft
fool with it.

Situation #2 can be pretty much anything else, since you make plans in
advance to correct any Microsoft-induced brain damage.

> My understanding of Apple's boot camp assistant is that it will only
> handle windows.  

It's closer to the truth to say Boot Camp Assistant is a bit clueless
about anything else, and needs to be coaxed/tricked into dealing with
other things, using rEFIt and some planning of your setup.  With that
quibble added, no, it's not true that Boot Camp Assistant works only
with MS-Windows.

http://wiki.onmac.net/index.php/Triple_Boot_via_BootCamp
http://www.helium.com/items/421906-how-to-install-linux-on-an-intel-mac-with-boot-camp
http://ubuntuforums.org/showthread.php?t=678542

> I have heard that you lose your video acceleration unless you are
> using GRUB2.

My understanding is that this is the case _if_ you don't boot using
Apple's BIOS emulation, and that adding in use of rEFIt addresses this
problem.  I could be wrong, but that's what I believe I read.

I have to stress once again:  I have zero relevant experience, and
deliberately eschew the complications of multibooting.  I've provided
URLs so _you_ can read up on it further, if you wish to use that approach.

> Although I do need something that isn't emulated, there will be
> times when I need more than one operating system going at the same
> time.  There is an open source program that does this.  It isn't
> really an emulator, but a virtual machine.

You keep using the words 'emulator' and 'emulated', even after I
carefully clarified that I have been speaking specifically of VM
software, and gave several examples (VMware Fusion, Parallels,
VirtualBox).  This leaves me wondering whether we're having the same
conversation, because I'm not sure what _you_ mean when you say your
usage scenario 'precludes use of emulators' / you 'need something that
isn't emulated'.

Perhaps we could have a more fruitful conversation if you wouldn't mind
being a bit clearer about what you're talking about.

> When are you folks having your next meeting?  

You know the old saying about teaching a man to fish?  Well, our
schedule is always available on the Web.
http://linuxmafia.com/cabal/

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