On Sunday 23 December 2007, Mikkel L. Ellertson wrote:
>Gene Heskett wrote:
>> On Saturday 22 December 2007, Mikkel L. Ellertson wrote:
>>> Unless you have 3 hard drives that the BIOS sees, this should still
>>> be 'root (hd1,0)'. This tells Grub to use the second BIOS drive,
>>> first partition.
>>
>> That's what I thought, but the 2nd bios drive is in fact a 350GB,
>> on ide cable 1, not 0, middle connector, so it would for ata style
>> access, be /dev/hdd, and there is no /boot partition on it, a gig
>> of swap & 20 GB of unused /var2, & the rest /dev/hdd3, is all for
>> amanda to use. Its labeled, so it can show up anywhere in the ide
>> chain and be found ok. There is a dvdwriter on /dev/hdc's ide1 end
>> cable position. The bios itself, does not see this added sata card,
>> a vmlinuz/initrd combo must be loaded from one of the bios visible
>> drives, which makes the sata drive visible. Booted to fc6/2.6.24-rc6,
>> a df looks like this:
>
>Because the BIOS does not see the drive, there is no hd2 as far as
>Grub is concerned. The only way to fix that is a BIOS upgrade, or a
>SATA controller with its own BIOS.
>
The bios is the latest for this board, dated September 2007. I was surprised
to see it available as the board is about 4 years old now, a biostar
M7NCD-Pro. Installing it changed the default FSB to 400MHZ, and an XP-2800
can only do 333MHZ. It crashed so quickly I had to dig out an old industrial
IBM keyboard with a ps2 connector in order to get into the bios and slow it
down again. Even usb stuff was dead.
It still doesn't see the card, and an lspci -v shows:
01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller
(rev 50)
Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller
Flags: bus master, medium devsel, latency 32, IRQ 21
I/O ports at 9400 [size=16]
I/O ports at 9800 [size=16]
I/O ports at 9c00 [size=16]
I/O ports at a000 [size=16]
I/O ports at a400 [size=32]
I/O ports at a800 [size=256]
[virtual] Expansion ROM at 50000000 [disabled] [size=64K]
Capabilities: [e0] Power Management version 2
Note the expansion ROM is disabled, and I've played with wine quite a bit
trying to make it run something, hell anything, from the little 3" cd that
came with the card, but wine apparently can't even see the cd. And I don't
know jack schidt about wine or winderz. Only one machine here with a copy of
xp on it, hasn't been booted to xp but once in a year+, to see how googles
sketchup is supposed to work.
I just tried to mount the disk, but its not mountable by any known M$ idiom
filesystem according to dmesg.
There may be something on the disk that could enable the extension rom, if one
could figure out what sort of a disk it is. I may take the card, and both
disks to a winderz box and explore it there to see if there is some sort of a
software switch to enable this, but that will be after Christmas now.
><--------------------[snip]------------>
>
>> So we have drives sca, sdb, and sdc (the sata drive on a via raid card)
>>
>> But when booted by the above mechanism, using a fedora kernel to f8,
>> the drive order is scrambled, with the now sdc becoming sda, hda becoming
>> sdb and what was hdd is now sdc.
>
>This is because of the order the drivers are loaded. The SATA drive
>is on the first "SCSI" controller, and the PATA drives are on the
>second "SCSI" controller. So the SATA controller is scanned forst
>for drives, and then the PATA controller. Drive letters are assigned
>in the order the drives are found.
What determines this scan order in the bootfile?
>> Humm that brings up another question, of what use is
>> /boot/grub/device.map file then? The 'grub-install --recheck'
>> re-wrote that file WITH the linux visible sata drive, like this:
>> (hd0) /dev/sda
>> (hd1) /dev/sdb
>> (hd2) /dev/sdc
>>
>> And with an fd0 entry as the first line I've since removed.
>>
>> If the bios can't see sdc, that last entry serves no usefull purpose
>> and the --recheck code needs fixed, its buggier than a 10 day old
>> deer carcass in August.
>
>The problem is that --recheck is only the best guess that Grub can
>make from the information it has. Once the system has booted the OS,
>there is no good way to determine the BIOS order of the drives. This
>is why the warning about verifying that the drive map is correct.
>
>With just about everything handled as SCSI drives now, there will be
>some problems that will have to be worked out. Partition labels take
>care of a lot of it by making drive order irrelevant, but you will
>have to be even more careful using programs like fdisk and dd. Grub
>will have a harder time guessing BIOS drive order, because the
>system drive order is not tied to the BIOS order at all, and the
>BIOS options for booting from other hard drives besides the first
>one, and for booting from USB drives, results in the BIOS order
>changing as well. The drive you tell the BIOS to boot from becomes
>the first BIOS drive.
Hummmm.... So take hd2 out of the device.map, its irrevelant anyway. But
that also will not fix this. The obvious fix is to make the bios extension
active. The 64K$ question is how.
>Mikkel
Thanks, and have a Very Merry Christmas, Mikkel.
--
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)
Q: How do you catch a unique rabbit?
A: Unique up on it!
Q: How do you catch a tame rabbit?
A: The tame way!
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
