GRUB update borks Debian testing

[Giles Orr]

As I've mentioned recently I'm using an external HD as the boot drive
(Debian testing) for an AAO netbook.  There's also a Debian testing
install on the AAO internal SSD.

A recent "aptitude update ; aptitude full-upgrade" while booted from
the external HD included an upgrade for GRUB (v2), which saw fit to
re-write all the GRUB-related system files and re-install GRUB, thus
making not only the external HD unbootable, but the internal as well.
That latter problem was particularly interesting: why exactly did an
upgrade on one drive touch the MBR of the other drive??

I understand a part of the problem: the external drive needs GRUB
config files that have it marked as "sda", but when it finishes
booting it becomes "sdb" and the internal drive is "sda".  I don't
know why or how that change of name(s) occurs, but when GRUB upgraded
itself it changed the configs to point to "sdb" because that was
clearly the drive it was installed on ... and once that was written to
the MBR the drive became unbootable.  Having rebooted before I
realized what had happened, I thought "fine, I'll fix it from the
other distro."  But when I attempted to boot the internal SSD, it said
it couldn't find a certain UUID (perhaps the external HD?).  But why
did it touch the other MBR at all?

So I plugged the external into another computer, fixed it ("mount
/dev/sdg /mnt/tmp", edit configs, then "grub-install
--root-directory=/mnt/tmp /dev/sdg"), plugged the external into the
AAO, booted off the external and fixed the internal.  This is NOT a
desirable dance card every time Debian sends out a GRUB update.
What's the best solution?

GRUB2 uses a highly abstracted set of scripts to generate its config
files: I had a reasonably good grasp on the GRUB1 files, but GRUB2
manages to be an order of magnitude more complex - and correspondingly
less useful in my opinion.  It's occurred to me to disable all the
GRUB scripts in /etc/grub.d/ and the whole updating mechanism for
/boot/grub/grub.cfg and just maintain it by hand.  But I don't even
know how to turn that mechanism off, and I'd like to give it more of a
chance before I discard it out of hand.  Not to mention that the next
GRUB update would probably re-activate the mechanism.

Your thoughts would be much appreciated!

-- 
Giles
http://www.gilesorr.com/
gilesorr-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists