On 2008/05/19 Mon PM 09:27:30 EDT cx8508 wrote
> try to enable the "SCSI disk support" and "Serial ATA (SATA) support" option
> in the kernel configuration, and compile them directly into the kernel, not
> as modules.
cx8508,
Thank you very much.
Please read on, if interested.
UPDATE
Since my last post I've been feverishly working on setting up a new "master"
LFS IDE disk on the old machine based on Phill Upson's, cx8508's suggestions
and whatever I could think of on my own.
So, I apologize for the delay in updating the situation.
I figured if I needed to make so many changes I might as well have them on the
latest kernel, 2.6.25.4. Compiling took a while though as the configuration
kept
fighting me all the way until I tracked down the bug to a relatively obscure
"NEW" parameter:
"SCSI device support > SCSI low level drivers > Marvell 88SE6440 SAS/SATA
support".
In my youthful impetuousness, knowing that Marvell is hot with the new SATA
boards these days, I foolishly enabled ("*" - as opposed to "M") this parameter
(we agreed that for the tests we should have as many functions in the kernel
proper as reasonably suspected to affect my IDE -> SATA failure).
The irony here is that my ICH9R might contain the Marvell 88SE6111 chipset(!)
(and not JMicron as suspected) to which I didn't see any reference in this
latest kernel. As an aside, this might be a real technical "marvell" to find
any support for it in my floppy's 2.4.2 kernel (for reference, my board P5E-VM
HDMI has been around since November last year)!
Now I am at the point where I'm preparing a solid, brand new "mirror" test
drive with all the desired flexibilities in order to attempt what should be my
last major effort in solving the problem. This may take a while.
All in all, if you don't hear from me with the results of a _successful_
operation within a few days it will be fair to assume I joined the Peace Corps
and moved to an undisclosed location without television or Internet.
On 2008/05/20 Tue PM 01:46:17 EDT Gerard Beekmans wrote
[Commenting in general, and specifically to my words:
"Just a thought (while we're at it): how come a lousy 2.4.2 rescue floppy can
get to my IDE drives (read/write) without my using any special HDD driver
machinations?"]
Mr. Beekmans,
First off, many thanks. Honored.
> Every kernel's default configuration enables a certain number of drivers to
> be built-in and a number to be modules. This set of enabled drivers is not
> always the same from kernel to kernel.
> It's therefore possible that your 2.4.2 kernel had different defaults than
> the one you are currently using. Meaning you need to reconfigure your current
> kernel to include the necessary IDE and SCSI drivers to match your hardware.
> And if they are already selected, make sure they are not modules.
It happens I was aware of that. For details please see above.
Here, I personally suspect a possible extra difficulty (actaully the crux of
all my theories - moving an IDE disk from a "natural" IDE board to a board
where the IDE port is "controlled" by some sort of a "bridge", like JMicron or
Marvell chipsets)
> While your kernel is booting up, pay close attention to its output.
> If your harddrive controller is recognized by a built-in driver, you'll see
> this on the output.
> When a physical disk is recognized, it will print out a line with the
> partitions it found (it'll print lines like hda1 hda2 hda3 or the sd variety).
> If you don't see anything matching your current harddrive configuration you
> can be fairly sure the kernel you compiled does not have the drivers
> necessary built-in.
This is a tough one. The speed of the displays nowadays is such that maybe one
of them high speed cameras might do the trick (like the one capturing the
bullet hitting the Master lock in the commercial).
I miss those 386SX-, 16M-, 256MB-Linux days!
> Just a reminder also - when you compiled a new kernel, don't forget to copy
> the actual kernel images to the /boot directory.
> Many people often reconfigure and recompile the kernel and then don't
> actually install it by copying the image.
> So you keep rebooting your *old* kernel expecting different results.
I always _fully_ test a disk set up for this project by physically connecting
it to the old ("PATA") machine. At a minimum, 'uname -a' works wonders for me.
Thanks again,
-- Alex
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
