Jim Householder <nofixed@???> writes:
> I have just bought a 500GB SATA Seagate Barracuda drive, and have built a
> kernel on it with all the SATA options I could find built-in (not modules).
>
> When I boot from the drive it gets as far as trying to mount / and panics.
> A list of partitions available does not show the SATA drive, event though
> the code that aborted was executed from it.
Do you mean "was executed from it" in the sense of "GRUB loaded the initrd and
kernel from it?"
Is the panic, specifically, that it can't find the root device?
When you say "A list of partitions", where is that coming from and what does
it show?
> I read somewhere that the newest SATA II drives take too long to initialise
> and are thus not seen.
Your information is wrong; SATA II disks take no longer than SATA I disks, and
neither of them is asynchronously scanned *UNLESS* you have specifically
enabled experimental kernel options to do precisely that.
> Since code from the drive is already being executed, that does not seem to
> be the problem.
You are probably wrong, and the answer to the question WRT the bootloader
above will confirm that. My guess is that Linux has never seen the drive,
even though the BIOS can.
> If it is, a firmware update is supposed to fix it.
This is extraordinarily unlikely to be the cause of, or resolution to, the
problem. Not least of which because, frankly, almost no one ever does a
firmware update on a consumer grade disk.
Now, one last question: why are you building a custom kernel rather that using
the distribution option? The distribution will almost certainly have the
right drivers available and configured sensibly, so you can avoid this problem
of doing it yourself entirely...
Regards,
Daniel
(text/plain)