Hiya,
menu.lst and menu.conf are lower priority than
/boot/grub/system.map
It is used by grub on every restart and MUST match the current parameters
installed into CMOS by the HDD controller during P.O.S.T.
It can go out of sync during a hot-swap.
It will go out of sync if you trade drive 0 for drive 1 (cold swap).
It will go out of sync if you add a new floppy drive (hot or cold).
It may go out of sync after Windows runs setup. ATA controllers
reset in Linux make CMOS parameters become wrong (fails on hot boot).
Unfortunately, your grub may now exist in duplicate /boot/grub folders.
This becomes a problem with the auto-install/update Debian scripts.
they use /etc for their config files (Deb versions above grub 0.97).
So you may have conflicting versions of grub and grub-install.
I still don't understand the grub in the Ubuntu distro.
So, I'd be guessing that your two-drive boot menu.lst was
working WITHOUT error only because you didn't notice /boot/grub/system.map
on multiple drives. Or maybe in multiple partitions of the same drive.
You should hunt down ALL the system.map files you may have collected.
Are they all the same? Are any different? grub-install creates it.
And beware of link pointers to /boot, they can become recursive.
The newer installations of Ubuntu seem to crash multi-drive
systems a lot because of this. Their install/conf relies not on /boot
but in /etc while using /boot/grub scripts.
These help control the newest&latest grub menu displayed under an XWindow server.
And may be handy as a "remote" grub.
The scripts eventually run grub-install which in turn uses /boot/grub
configuration files (that may now be out of sync). The scripts are
a lil over my head, but seem (to me) to also ignore the /boot/grub/system.map
and instead rely on drive info stored elsewhere in /etc/grub somewhere...
I've given up on grub versions above 0.97 since even Fedora 12 is shipped
with 0.97. Newer grubs, packaged and script-controlled under Ubuntu
can't yet be trusted. IMHO. Versions 1.0 and above are not backward-compatible.
The grub error you report may be caused by swapped partition-info being
actively used, after a changed (and now incorrect) partition, without a power-down.
ie. Filetype changes before and after a Debian scripted, grub-install.
I would like to know more about your system's progress.
That is to say, power-down is required of ATA controllers when changing
any BOOT drives/partitions. It allows drives to report correctly to P.O.S.T.
Drive controllers hold partition numbering info until powered off.
Software scripts can't fix this, although they try.
If you have mirrors of /boot/grub how will you know WHAT booted the grub menu?
For me, I dedicate a whole ext2 partition (usually hd0,6) to ONE /boot and force new
Linux installations to mount it on /boot with NO formatting.
Seems like everyone is playing with /etc/fstab nowadays too.
This message-----
> root (hd0,4)
> Filesystem type is ext2fs, partition type 0x83
> kernal.....
> [Linux-bz-Image, setup=0x3000, size=ox16ce50]
> Error 24 Attempt to access block outside partition
-----
Is not a Linux filesystem error it is from grub.
Stage 2 of grub (after the menu display) is trying to read and load
the selected kernel from Drive 0, Partition 4 (not a logical partition).
Failure is prolly 'cause it's not there, but used to be on Drive 1, Partition 4.
(-: Chas.M. :-)
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss 
(text/plain)