It seems that the problem that I have regarding SATA and IDE HD's and
Ubuntu/Kubuntu 8.04 Hardy are related more to a known Grub bug than
anything else.
Booting my Hardy install using the LiveCD to boot from 1st HD allows the
system to see the SATA hd, though it does shuffle the IDE drive
designations by a step ( ie prim master becomes /sdb because the STA hd
becomes /sda). The syatem still boots but a problem arises because /home
is (was) on /sda2 which is now /sdb2 and isn't found.
My solution ( as I often remove the SATA hds which are data only) is to
either setup a system with only SATA hds or to revert to an older distro
such as the last LinuxMint on another PC which sees IDE hds as /hdxx and
SATA hds as /sdxx)
Another alternative is to ditch Grub and install Lilo I believe.
Ny the way, the 3 mobos I'm using are all Gigabyte , approx 3 years old,
and have 2 xIDE, 2 x IDE(RAID) and 2 x SATA ( RAiD) both RAIDS being
able to be used as non-RAID.
----------------------------------------------------------------------------------
---------------------------------------------------------------------------------
Refs:-
http://www.fsckin.com/2007/10/30/in-depth-roadmap-analysis-for-ubuntu-hardy-heron-804/
# RudieD | November 2nd, 2007 at 5:30 am
In-Depth Roadmap Analysis For Ubuntu Hardy Heron 8.04
Linux October 30th, 2007
Comment
I agree with the Bug fixing, but one bug that really bugs me is that
GRUB bug with combo of IDE and SATA drives.
I understand that GRUB has to fix their bugs (or somone who knows the
details), but they don’t and I don’t know how.
Maybe Ubuntu can look at another boot manager that can work ?
--------------------------------------------------------------------------------
http://www.mepislovers.org/forums/archive/index.php?t-14990.html
http://www.mepis.org/docs/en/index.php/Grub_with_IDE_and_SATA_Drives
Now that I've read that, I believe your problem is entirely in the
failure of the Grub installer to predict the drive numbering that the
BIOS will give to Grub. That issue is certainly discussed in the Grub
documentation, where it seems to be just accepted that some users will
need to override the default behavior.
I don't know if it is practical for an individual distribution to make a
more user friendly work around for this issue. I doubt one could do a
really great job of guessing the BIOS behavior. I don't know whether the
data given by the BIOS to Grub is still available when the kernel
starts, and if so, whether it is still available when init code starts.
If so, it could be used by startup code on the liveCD to use the actual
info provided by the BIOS to predict the info that will be provided by
the BIOS.
You are correct: apparently it is a well-recognized problem that GRUB
does not do well at guessing BIOS drive mapping. As far as the rest of
your comment --that's where my level of knowledge ends. I don't
understand the mechanics of that process in detail. Apparently it is not
straightforward, though, or it would have been fixed in the Mepis 7.0
Beta stages.
---------------------------------------
http://www.mepis.org/docs/en/index.php/Grub_with_IDE_and_SATA_Drives
Some comments about the explaination:
The BIOS drive order will usually depend on whether the mobo considers
sata or ide to by the primary drives. In other words, newer mobos are
more likely to have sdX first.
Actually sd means SCSI Drive.
The kernel does not, per se, determine the relative order of hda and sda
drives as used by GRUB. The kernel just determines which device name is
associated with which drive.
Before booting, GRUB uses the "natural" order of the drives as presented
by the BIOS.
And after loading the kernel, GRUB applies what appears to be a complex
algorithm that takes into account which drive is the BIOS designated
boot drive, the actual boot drive for the OS, and the natural order of
the drives. During grub install this algorithm is used to determine the
appropriate drive order and creates a devices.map, unless a devices.map
already exists.
Theoretically if the devices.map were generated properly either manually
or by a code fragment, before calling grub install, then the menu.lst
would be created correctly. But I haven't had time to verify this.
This is a well known problem with grub but it was not a major issue
until newer mobos came out that mixed ide and sata. AFAIK, every distro
that uses grub has this problem, except ubuntu which is trying to use
UUIDs to identify the drives, but there are reports that this also does
not work reliably.
---------------------------------
--------------------------------
Thanks to all who replied with suggestions.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
