[SLL] Help! Blew away partition table

[Tim Maher]

Short version:

*** Anybody know a way to reset a disks' partition table in the MBR to
the one in memory that's currently being used for it?

Long version"

My development system is in a bad way. Last night, I performed
an "upgrade" from SuSe 10.0 to 10.1, which took so long that
I left to watch a movie after it got cooking. When I returned to the
machine (at 2am), there was a garbled GRUB shell display on the screen,
looking approximately like this:

  GRUB> asdgfigqe a0bvqe=rg0g 077*&++R&R

  GRUB> <I pressed enter>

  "insufficient memory for requested command" (or something similar)

So I rebooted from the installation disk, and tried some of the fairly
extensive "repair" options, including "try lots of fixes" (or some such
thing", "reinstall GRUB" and "reinstate MBR".  I also booted from a GRUB
floppy, and specified the kernel path and such, but when I told it to
boot from the 2nd disk (as I normally do), I got a message that went
something like this:

PANIC can't mount root FS. bad root= option, or bad stuff in block (0,0)

The root option was set to /dev/hdb8 (kernel /boot/vmlinuz root=/dev/hdb8
ro), and I had already done "root (hd1,7)" and "setup (hd1)" successfully.

I tried different things to fix this for the next few hours, including
restoring backed-up mbr records from the hard disk, whose partitions I
could successfully mount and examine in a virtual terminal.

Imagine my horror when I ran fdisk on hdb to check its partitions, and
I recognized hda's 4 partitions there, instead of hdb's 16!  I suppose I
had accidentally reloaded the wrong mbr to disk 2. 8-{  Stuff like that
can happen at 3am.

My next step was to run the "recover lost partitions" option from
the SuSe CD, which took about 6 hours. I was very happy to see
most of my old (almost all 20g) partitions listed in the file called
YaST2*/osr_log. However, back in the GUI view, it's asking me which of
various 304g, 10.7g, and 4.7g partitions I want to restore, without a
single 20g one listed! 

The two disks are different brands and different sizes, so hdb
can't be interpreted correctly using hda's CHS settings.
So I'm wondering if the GUI is using the CHS settings from the
new (bad) partition table, while gpart is using the (good) ones
still in memory.

Fortunately, I haven't rebooted since the hdb mbr clobberation, so I
can /still/ mount hdb's partitions and look at the data. I've recently
backed-up the most indispensable data from that drive, I'm happy to
say. But I'd much rather restore this disk's partition table than rebuild
the whole thing from scratch!

So here is my main question, apart from the obvious "What should I do?"

*** Anybody know a way to reset a disk's partition table in the MBR to
the one in memory that the kernel is currently using for it?

Sigh,
--Tim 
P.S. I'm saving some critcal stuff to floppies and the hda drive,
so I won't lose access after a reboot.
*====================================================*
| Tim Maher, CEO, Consultix  (206) 781-UNIX/8649     |
| tim at consultix-inc.com   www.consultix-inc.com      |
*====================================================*