Greetings;
Is there a utility that can query the motherboard bios and get a list of the
drives it can see?
Likewise, for the bios extension contained on a pny sata card with a Silicon
Image chipset on it?
I'm trying to cobble up a way for linux to boot from the drive on this sata
card, so that the F8 install is completely separated from the FC6 install on
a pata drive connected to the mainboard.
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Alea iacta est.
[The die is cast]
-- Gaius Julius Caesar
Gene Heskett wrote:
> Greetings;
>
> Is there a utility that can query the motherboard bios and get a list of the
> drives it can see?
>
> Likewise, for the bios extension contained on a pny sata card with a Silicon
> Image chipset on it?
>
> I'm trying to cobble up a way for linux to boot from the drive on this sata
> card, so that the F8 install is completely separated from the FC6 install on
> a pata drive connected to the mainboard.
>
No, but if you configure in EDD support (and don't disable it), then the
kernel will do so on your behalf during early boot.
Unfortunately, it is not trivial to produce a mapping from EDD data to
real-life disks. Your best bet is if the disks have an MBR signature,
in which case the EDD code will capture those; you can then correlate
them to real disks.
-hpa
> Unfortunately, it is not trivial to produce a mapping from EDD data to
> real-life disks. Your best bet is if the disks have an MBR signature,
Untrue for all but the very earliest EDD. True for our kernel support
which wants improving some day
> in which case the EDD code will capture those; you can then correlate
> them to real disks.
EDD 1 provides the I/O base of each BIOS device so you can cross corelate
at least each IDE device with the BIOS identifier. EDD 3 provides paths
in multiple forms including PCI identifiers which serve the same purpose.
Unfortunately our EDD boot code doesn't capture the right bits in all
these cases.
Alan Cox wrote:
>> Unfortunately, it is not trivial to produce a mapping from EDD data to
>> real-life disks. Your best bet is if the disks have an MBR signature,
>
> Untrue for all but the very earliest EDD. True for our kernel support
> which wants improving some day
>
>> in which case the EDD code will capture those; you can then correlate
>> them to real disks.
>
> EDD 1 provides the I/O base of each BIOS device so you can cross corelate
> at least each IDE device with the BIOS identifier. EDD 3 provides paths
> in multiple forms including PCI identifiers which serve the same purpose.
>
> Unfortunately our EDD boot code doesn't capture the right bits in all
> these cases.
That's true for IDE, definitely, but for other drive technologies the
information can be ether inadequate or downright misleading...
especially when dealing with complex disk topologies. Worse, as one
could expect, the information provided is downright wrong in many cases.
To make matters worse, the EDD standard doesn't have a maintainer, so
new technologies aren't assigned new identifier.
What you'd want is a way to query the disk serial number, but EDD
doesn't provide that (there is the "packet interface", but it doesn't
seem to be widely implemented.)
-hpa
On Fri, Jan 04, 2008 at 07:13:53PM -0500, Gene Heskett wrote:
> Greetings;
>
> Is there a utility that can query the motherboard bios and get a list of the
> drives it can see?
>
> Likewise, for the bios extension contained on a pny sata card with a Silicon
> Image chipset on it?
>
> I'm trying to cobble up a way for linux to boot from the drive on this sata
> card, so that the F8 install is completely separated from the FC6 install on
> a pata drive connected to the mainboard.
parted and fdisk both write into the MBR signature space, so your
disks should have unique MBR values in them.
Then, F8 anaconda / kickstart can be told on which disk to write its
bits. http://linux.dell.com/installermagic.shtml describes this.
I've given up trusting any BIOS to get EDD 3.0 device paths right,
there are just too many broken implementations out there, and
seemingly no real desire on the part of the component vendors to fix
it. MBR signatures work pretty well - Dell uses this method for every
one of our factory installed Linux systems we ship, so I _know_ it works.
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & http://www.dell.com/linux
Matt Domsch wrote:
>
> parted and fdisk both write into the MBR signature space, so your
> disks should have unique MBR values in them.
>
parted did so incorrectly, and had less than 20 bits of randomness.
fdisk only does so as of a very recent version (I put that in after I
noticed a whole bunch of disks I had had zero identifiers.)
sfdisk doesn't at all, last I checked.
None check for collisions.
> I've given up trusting any BIOS to get EDD 3.0 device paths right,
> there are just too many broken implementations out there, and
> seemingly no real desire on the part of the component vendors to fix
> it. MBR signatures work pretty well - Dell uses this method for every
> one of our factory installed Linux systems we ship, so I _know_ it works.
At least with a known distribution. But yes, it really seems to be the
most reliable method.
-hpa