Lindsay Haisley posted on Sat, 11 Sep 2010 18:36:21 -0500 as excerpted:
> On Sat, 2010-09-11 at 17:08 -0500, Brent Busby wrote:
>> So the switch from /dev/hd* to /dev/sd* for such devices isn't just
>> cosmetic -- everything is now being handled by libata (which is the
>> Sata drivers), and if you have any Pata device drivers in your kernel
>> config, you'll want to get rid of those and replace them with
>> equivalent drivers from the Sata section of the kernel.
>> Not doing this will cause very strange behavior with regard to DVD
>> drives in udev and hal, especially if you use Gnome.
> Ugh!! This sounds like the roadblock I ran into! The problem drive,
> /dev/hda, holds the root filesystem and several others, and didn't show
> up at all in /dev. Since the system also has several SATA drives, I'm
> using the sata_promise kernel module for these, but the SATA system on
> the MB is managed by a Promise chipset, which supposedly implements
> hardware RAID but it's proprietary so I'm just using plain old discrete
> non-RAID mode.
JBOD (just a bunch of disks) mode. I use it here, too. FWIW, I'm running
all SATA hard drives but the DVDRWs are PATA. I've been running an sdX
config for years (since I switched to kernel 2.6??), but did have to
change the fstab lines for the DVDRWs when I switched them over. They're
sr0 and sr1 now.
From what you wrote earlier, I thought you had all SATA hard drives but
were depending on udev's compatibility rules to setup hdX symlinks to the
sdX devices, using the hdX symlinks in your fstab. If you're still using
pata and the devices themselves were hdX but are now sdX, that's a
different issue and there's a bit more excuse... tho as mentioned really
only if you've been living in a cave or under a rock for some years.
If you configure your own kernel, you should have run into that when doing
the make oldconfig, and could have adjusted accordingly then. But if you
depend on genkernel... well, let's just say I like to know what changes
are going on with my kernel, and that's one of the reasons I don't use
genkernel. (Tho for all I know, there was a warning when genkernel did
the change too, but I wouldn't know, as I don't use it.)
> I have rather a conflict here, since I already have a /dev/sda.
See vvv (below, those are arrows).
> Is there a HOWTO for using libata-supported kernel components, and
> configuring them in the kernel?
Someone familiar with the specific hardware you have might know exactly
what order (vvv) the devices would appear in, but I'm not, so it's of no
significance to me and I snipped it. I explain the general situation vvv.
> The linux kernel here already has CONFIG_ATA_PIIX, which supposedly
> talks the lingo of the ICH series I/O controller hub. What else do I
> need here, or where can I go to learn more?
As it did with hd* devices, the kernel assigns default sd* device names in
the order it detects them.
Generally speaking, for desktop and SOHO server systems, the detected
order remains relatively consistent, so using /dev/sdX type identifiers is
fine. Of course, in enterprise equipment with perhaps hundreds of drives
attached, that's not the case, but we're not talking that high a level
here, and obviously the detected order had remained the same before, so
presumably it will continue to do so... with very occasional exceptions
that tend to be noted well in advance (and warned about in ewarns for
Gentoo users who read them, even if they don't keep up with general Linux
news), for those following them.
The switch to libata and sdX devices by default, for PATA devices as well
as the SATA devices that pretty much always were sdX, was one such
exception. That happened quite some time ago in the kernel and I've long
since forgotten the articles I read on it, but they should be googlable if
The short version, however, is that for users with both PATA and SATA
devices who previously had both sdX and hdX drives, obviously, the
numbering is going to have to change with the switch to all-sdX. This is
a one-time change, however, and at least for consumer/SOHO level systems,
once the change is configured for, ordering should remain stable once
again for quite some time.
So here's the deal. You're upgrading over a huge gap, so the transition
won't be as smooth as it could be. But you already know the way to make
your root filesystem writable and etc from the previous trial, which will
What you need to do is boot the new kernel/udev and note the device
ordering. You should have /dev/sdX devices for all hard drives now, both
PATA and SATA. What you need to do is figure out what the actual order is
-- as I said it should remain stable (as long as you don't change the
hardware config), but you have to figure it out, in ordered to put the
correct names in fstab.
Among other things, udev should create symlinks for each device UUID/GUID
to the associated name, and if you write down which GUID applies to which
device on your current system, you can use that to figure out which sdX
they end up on with the new layout.
One hint is that the kernel will probably pick an adaptor and enumerate
everything on it, then go on to the next one. So if you have two adaptors,
one with two devices and one with four, and it picks the one with four
first, that should fill up sda thru sdd, with sde and sdf from the one
with two, following. If it picks the other order, you'd have sda and sdb
from the two-drive adaptor, then sdc thru sdf from the four-drive adaptor.
As mentioned ^^^, order should remain consistent over boots as long as the
hardware config doesn't change, you just have to figure out which one
comes first once, and it should remain that way.
Once you've noted the order and figured out which sdX corresponds to which
device, make your rootfs writable as you did before, and change the
corresponding fstab and intermediate layer (lvm/dmraid/mdraid/etc) configs
so the mapping is to the new device names instead of the old ones. You
can then reboot, and it should come up as normal. =:^) (If it doesn't,
there's probably a mapping you forgot to change, somewhere.)
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman