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
