[gentoo-desktop] Re: Desktop problem with /dev/hda

[Duncan]

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 
you're interested.

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 
help.

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