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

[Lindsay Haisley]

On Sun, 2010-09-12 at 00:52 +0000, Duncan wrote:
> Lindsay Haisley posted on Sat, 11 Sep 2010 18:36:21 -0500 as excerpted:
> > 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.

JBOD - That's like POTS in telco terminology :-)  I was trying to think
of JBOD but couldn't remember it.

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

No, the MB has an Intel chipset with a standard PATA header/port, but it
also has an onboard Promise controller and 4 SATA connectors intended to
support RAID.  I never could get the Linux hacks with the proprietary
Promise RAID controller to work properly, so I just set them up JBOD and
incorporated them into Linux RAID-1 arrays.

This isn't as bad as our firewall/file server box!  I have that set up
with EVMS, and it boots from an initrd right into EVMS, so the boot
drive is a Linux RAID array.  Now EVMS has been abandoned (pity, it was
a great idea!) and the box is living on borrowed time as far as upgrades
are concerned.  It was a daring trick, but it'll probably bite us in the
butt eventually!

>  tho as mentioned really
> only if you've been living in a cave or under a rock for some years.

I like caves, and under rocks, too ;-)  I have a life outside of
geek-land and these days it's looking pretty cool.  I do fall behind on
this stuff, though, as a result.

> 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 don't use genkernel either, for the same reasons.  I've been
configuring my own kernels since Linux kernel 1.something.  That kinda
dates me, I guess.  The only thing genkernel is good for is if you
_have_ to build an initrd, but I had to do that by hand anyway when I
set up our in-house file server because I had to build EVMS support into
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.

Duncan, thanks for your notes and observations.  Most of this I already
know, but it's always encouraging and helpful to have someone else lay
it out.  I'll probably take another run at the upgrade when my time
permits, which it doesn't right now.  I just need to make sure that I
have a path to back out of any changes, as I did earlier this week, if
things get foobar.  I have to be able to get to a stable, bootable
desktop at the end of the day, whether it's running the old kernel or a
new one.

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

I can also look at them with cfdisk and figure it out from the partition
layout - which is probably easier.  I would assume the SATA drives will
be in the same order.  The hard drives are also identified by model and
what I assume to be the serial number in /dev/disk/by-id - e.g.
"ata-WDC_WD360GD-00FNA0_WD-WMAH91500602" - which is, in a pinch, also
printed on the drive cases.

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

grep -R hd /etc/lvm/* says that the only place that "hd" is mentioned
(other than in comments) is in /etc/lvm/cache/.cache, which I would
assume I could erase and the LVM system would re-create it.  "sd" isn't
in there at all.  I'll also have to edit /etc/mdadm.conf which makes
specific references to /dev/sd* partitions by name.

> can then reboot, and it should come up as normal. =:^)  (If it doesn't,
> there's probably a mapping you forgot to change, somewhere.)

... and if it fails, I go and cry myself to sleep and work on it the
next day ;-)

-- 
Lindsay Haisley       |  "Humor will get you through times of no humor
FMP Computer Services |      better than no humor will get you through
512-259-1190          |         times of humor."
http://www.fmp.com    |            - Butch Hancock