Kernel Upgraded from 2.6.17 to 2.6.20

person132 · 04-14-2007, 06:17 PM

The title describes the problem fairly well - I was running 2.6.17.13 (I think), and I upgraded to 2.6.20 (I compiled both kernels, the second one using make oldconfig). Now, it sees my SATA hard drive as /dev/hda rather than /dev/sda; this is causing some problems, esp. with fstab (I was only able to boot by passing root = /dev/hda4. Is this normal? Should I just adjust to the new device nodes? Is there a kernel config option or other method for getting it to recognize the drive as what it is?

Quakeboy02 · 04-14-2007, 06:46 PM

What motherboard and controller are you using, and did you change any BIOS or config options for the new kernel? I haven't run into this problem, and I've upgraded successively through the 2.6.19 kernels to now 2.6.20.6.

person132 · 04-14-2007, 09:09 PM

Thanks for the reply. I did not change and BIOS settings; the hard drive is set as the IDE primary master, even though the drive itself is SATA. I have little information besides it being an Asus motherboard, as this is a laptop.

The output from lspci -v sheds some light on the matter, I beleive:

Code:

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) (prog-if 80 [Master])
        Subsystem: ASUSTeK Computer Inc. Unknown device 1447
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at ffa0 [size=16]
        Capabilities: [70] Power Management version 2

From this, it appears to be a controller that interfaces with the BIOS by IDE while controlling a SATA drive.

The question, now, is why the 2.6.17.13 kernel assigns it a /dev/sda designation while the 2.6.20.7 kernel recognizes it as /dev/hda.

Quakeboy02 · 04-14-2007, 09:14 PM

"The question, now, is why the 2.6.17.13 kernel assigns it a /dev/sda designation while the 2.6.20.7 kernel recognizes it as /dev/hda."

I seem to remember seeing something about this on the switch from 2.6.17 to 2.6.18 and beyond, but I'll be damned if I can remember what or where. It kind of makes sense that the way the BIOS sees the drive should take precedence, though.

syg00 · 04-14-2007, 09:31 PM

Changes were introduced at .18, and .19 - see this for pertinent .19 stuff.

Edit: It really does pay to keep an eye on the (kernel) changelogs. You might be used to just compiling it, but when it all falls apart, start looking at those changelogs. All of them.
I recall at least one occasion recently where Andrew Morton (in his changelog) has specifically warned against just habitually using oldconfig.
When you get bit, go looking for why.

HappyTux · 04-14-2007, 09:32 PM

Quote:

Originally Posted by Quakeboy02

I seem to remember seeing something about this on the switch from 2.6.17 to 2.6.18 and beyond, but I'll be damned if I can remember what or where.

The naming for the modules changed from CONFIG_SCSI_SATA_???? to CONFIG_SATA_???? which an oldconfig compile probably never picked up. Check in your old 2.6.17 config file comparing to the new 2.6.20 to see which module(s) did not get built for the SATA options.

syg00 · 04-14-2007, 09:34 PM

D'oh - was supposed to be an edit, note a quote.
Deleted; see post above.

Quakeboy02 · 04-14-2007, 09:39 PM

Quote:

The naming for the modules changed from CONFIG_SCSI_SATA_???? to CONFIG_SATA_???? which an oldconfig compile probably never picked up.

Thanks for the info Happy Tux. I've never really relied on oldconfig, so I guess I just never saw the problem, but I knew *something* had happened.

person132 · 04-15-2007, 08:51 PM

A quick recompilation with the appropriate SATA drivers fixed everything. Thanks for all your help.