Desktop problem with /dev/hda
 

I recently tried a badly needed kernel upgrade on my desktop system,
moving from kernel 2.6.23-gentoo-r3 to kernel 2.6.29-gentoo-r5. This
also required an upgrade of udev from 141 to 151-r4. When I rebooted
the box there was no /dev/hda4 which is normally the root filesystem,
and instead what was the root filesystem had a device name of, I
believe, "rootfs" in the kernel mount table which had the same files. A
number of other mounts were gone as well (there was no /dev/hda at all,
which has several partitions).

The boot-up stumbled to a halt at a maintenance mode prompt with the
root filesystem mounted R/O and of course no gnome desktop. I could use
mount -o remount,rw / to make the root filesystem RW, which allowed me
to re-emerge an earlier version of udev and boot to the previous kernel,
but I'm stuck with an aging kernel, and other tools depend on a kernel
and udev upgrade so sooner or later I'm going to be just, plain,
stuck :(

The drive setup is a bit complex. The actual hard drive mounting
(excluding things like proc, udev, devpts, etc.) look like:

/dev/hda4 on / type reiserfs (rw,noatime)
/dev/mapper/main_vg-fmouse on /home/fmouse type reiserfs (rw,noatime,notail)
/dev/hda1 on /home/fmouse/win98 type reiserfs (rw,noatime,notail)
/dev/mapper/main_vg-win_xp on /home/fmouse/winxp type reiserfs (rw,noatime,notail)
/dev/mapper/main_vg-backup on /home/fmouse/winxp2 type ext3 (rw,noatime)
/dev/mapper/main_vg-archive on /home/fmouse/archive type reiserfs (rw,noatime,notail)
/dev/hda2 on /boot type ext3 (rw,noatime)

The /dev/mapper/main_vg-* block devices are LVM logical volumes
consisting of Linux RAID-1 arrays which contain an archive and a couple
of filesystems for a VMware installation. The underlying drives are
SATA drives which show up as /dev/sd[a-d]1 in /dev.

This setup must be maintained in a functional state across any kernel
and udev upgrades.

I've been careful to use the .config from the working kernel as the
start for configuring a kernel for the newer kernel, using make
oldconfig.

Does anyone have any idea what's wrong here? Am I required in recent
kernels to identify all physical drives in /etc/fstab (and anywhere else
it matters) with a UUID instead of a /dev device name? I've wasted an
entire day on this problem, which I can ill afford, but I have to get
past this roadblock and get my kernel up-to-date.

--
Lindsay Haisley | "In an open world, | PGP public key
FMP Computer Services | who needs Windows | available at
512-259-1190 | or Gates" | http://pubkeys.fmp.com
http://www.fmp.com | |

Desktop problem with /dev/hda
 

Lindsay Haisley wrote:

I recently tried a badly needed kernel upgrade on my desktop system,
moving from kernel 2.6.23-gentoo-r3 to kernel 2.6.29-gentoo-r5. This
also required an upgrade of udev from 141 to 151-r4. When I rebooted
the box there was no /dev/hda4 which is normally the root filesystem,
and instead what was the root filesystem had a device name of, I
believe, "rootfs" in the kernel mount table which had the same files. A
number of other mounts were gone as well (there was no /dev/hda at all,
which has several partitions).

The boot-up stumbled to a halt at a maintenance mode prompt with the
root filesystem mounted R/O and of course no gnome desktop. I could use
mount -o remount,rw / to make the root filesystem RW, which allowed me
to re-emerge an earlier version of udev and boot to the previous kernel,
but I'm stuck with an aging kernel, and other tools depend on a kernel
and udev upgrade so sooner or later I'm going to be just, plain,
stuck :(

The drive setup is a bit complex. The actual hard drive mounting
(excluding things like proc, udev, devpts, etc.) look like:

/dev/hda4 on / type reiserfs (rw,noatime)
/dev/mapper/main_vg-fmouse on /home/fmouse type reiserfs (rw,noatime,notail)
/dev/hda1 on /home/fmouse/win98 type reiserfs (rw,noatime,notail)
/dev/mapper/main_vg-win_xp on /home/fmouse/winxp type reiserfs (rw,noatime,notail)
/dev/mapper/main_vg-backup on /home/fmouse/winxp2 type ext3 (rw,noatime)
/dev/mapper/main_vg-archive on /home/fmouse/archive type reiserfs (rw,noatime,notail)
/dev/hda2 on /boot type ext3 (rw,noatime)

The /dev/mapper/main_vg-* block devices are LVM logical volumes
consisting of Linux RAID-1 arrays which contain an archive and a couple
of filesystems for a VMware installation. The underlying drives are
SATA drives which show up as /dev/sd[a-d]1 in /dev.

This setup must be maintained in a functional state across any kernel
and udev upgrades.

I've been careful to use the .config from the working kernel as the
start for configuring a kernel for the newer kernel, using make
oldconfig.

Does anyone have any idea what's wrong here? Am I required in recent
kernels to identify all physical drives in /etc/fstab (and anywhere else
it matters) with a UUID instead of a /dev device name? I've wasted an
entire day on this problem, which I can ill afford, but I have to get
past this roadblock and get my kernel up-to-date.





I ran into this a few weeks ago. I to have the old IDE hard drives. I
had to switch to PATA which means my drives are now sd* instead of hd*.
I don't use LVM tho. I set LABELS on mine and use that to boot and
mount the partitions where that are supposed to mount. It worked pretty
well and since I'm using LABELS I can also boot the older kernels and
hopefully any future kernels that come out.


I *think* LVM can use LABELS to. If so, that would be my suggestion.
That way you can move things around as needed and them still boot as
they still be able to find your partitions.


So far, I have not been able to get Grub to see the LABELS. I just
haven't been able to do much testing on it yet.


I'm not sure this will help you but it may be something that you want to
check into. If LVM can work with this, it should be backward compatible
with the kernels.


Hope that gives you a idea at least.

Dale

:-) :-)

Desktop problem with /dev/hda
 

Dale posted on Thu, 09 Sep 2010 21:16:49 -0500 as excerpted:

> Lindsay Haisley wrote:
>> I recently tried a badly needed kernel upgrade on my desktop system,
>> moving from kernel 2.6.23-gentoo-r3 to kernel 2.6.29-gentoo-r5.

I'll say! Even 2.6.29 is ancient. 2.6.35.4 is I believe the current
release, and I'm running 2.6.36-rc3. (I run linus git directly, but he
has been away at a conference and there haven't been any updates for some
days, so current git is still the rc3 he put out before he left... unless
he got back and did some commits today.)

But I'm curious; why 2.6.29? 2.6.27 was a long-term-stable-support
release, still currently supported tho likely not for a lot longer, unless
someone else picks it up, as the maintainer says he's about done with it,
while 2.6.29 was on a normal release support schedule, AFAIK, with stable
updates for it ending probably sometime after the +2 release (2.6.29 +2 =
2.6.31).

2.6.32 is the current long-term-stable-support release. If I were running
my kernels as long as you do, that's what I'd be upgrading to, because
it'll be supported (and get security and bug patch support in further
stable releases) for some time yet, not the 2.6.29 that's no longer
upstream supported.

I'd STRONGLY suggest you do whatever research you might wish to, to
confirm what I just stated, and then then seriously consider 2.6.32.
Either that, or go back to 2.6.27, because altho its support is about to
end (again, unless someone else picks it up), it has been supported as a
long-term-stable for quite some time now and has a lot more of the bugs
worked out than 2.6.29 will ever get.

>> This
>> also required an upgrade of udev from 141 to 151-r4. When I rebooted
>> the box there was no /dev/hda4 which is normally the root filesystem,
>> and instead what was the root filesystem had a device name of, I
>> believe, "rootfs" in the kernel mount table which had the same files.
>> A number of other mounts were gone as well (there was no /dev/hda at
>> all, which has several partitions).

You were playing irresponsible gentoo sysadmin who wants to live on the
edge and risk breaking stuff because you didn't read your ewarn summaries,
weren't you? Especially with boot-critical packages like udev, and
*ESPECIALLY* when you're upgrading that far, you **REALLY** **NEED** to
read those messages.

Excerpt from udev-151-r4.ebuild:

if use old-hd-rules; then
ewarn
ewarn "old-hd-rules use flag is enabled"
ewarn "This adds the removed rules for /dev/hd* devices"
else
ewarn
ewarn "This version of udev no longer has use flag old-hd-
rules enabled"
ewarn "So all special rules for /dev/hd* devices are
missing"
fi
ewarn "Please migrate to the new libata if you need these rules."
ewarn "They will be completely removed on the next udev update."

Neither did you check the USE flag changes that emerge --pretend or emerge
--ask would have shown you. From equery uses =udev-151-r4:

- - old-hd-rules : Install rules for /dev/hd* devices, removed upstream
at udev-148

>> The boot-up stumbled to a halt at a maintenance mode prompt with the
>> root filesystem mounted R/O and of course no gnome desktop. I could
>> use mount -o remount,rw / to make the root filesystem RW, which allowed
>> me to re-emerge an earlier version of udev and boot to the previous
>> kernel, but I'm stuck with an aging kernel, and other tools depend on a
>> kernel and udev upgrade so sooner or later I'm going to be just, plain,
>> stuck :(

What's it they say about naughty gentoo sysadmins who can't do responsible
upgrades, checking their USE flag changes or AT LEAST the ewarn
summaries? Oh, yeah, "If it breaks, you get to keep the pieces." Well,
you didn't read either one, and not without surprise for something left
that long, then upgraded irresponsibly, entirely heedless of any warnings
or USE flag changes, it broke...

Of course, it /is/ fixable. You won't be left with pieces that you can't
put back together. =:^)

>> The drive setup is a bit complex. The actual hard drive mounting
>> (excluding things like proc, udev, devpts, etc.) look like:
>>
>> /dev/hda4 on /

>> The underlying drives are SATA drives which show up as
>> /dev/sd[a-d]1 in /dev.
>>
>> This setup must be maintained in a functional state across any kernel
>> and udev upgrades.

You said it, not me. It must be /maintained/. That's a responsibility.
Gentoo can't do that for you, neither does it even try to. If you can't
even read the warnings the gentoo devs spend their time on... <shrug>

You also said it yourself. The devices are /dev/sd*, not /dev/hd*. The
direct change to your fstab (and lvm and etc config, if necessary), then,
should be pretty simple, a pretty much direct substitution: s/hd/sd/g
(substitute, for hd, sd, globally). It's possible the [a-d] bit will
change order, but I doubt it, as you've been depending on udev's hd rules
for some time now, and I'm almost certain (without actually checking, one
could check the udev ruleset if they wanted to be sure) they default to
using the same device letter if possible.

>> I've been careful to use the .config from the working kernel as the
>> start for configuring a kernel for the newer kernel, using make
>> oldconfig.
>>
>> Does anyone have any idea what's wrong here? Am I required in recent
>> kernels to identify all physical drives in /etc/fstab (and anywhere
>> else it matters) with a UUID instead of a /dev device name? I've
>> wasted an entire day on this problem, which I can ill afford, but I
>> have to get past this roadblock and get my kernel up-to-date.

If you couldn't afford it, why did you crassly upgrade a boot-critical
package and then reboot, without reading the ewarns, /especially/ when
upgrading that far at once? Do you regularly play Russian Roulette as
well? How many bullets do you load when you do?

Come on! This isn't rocket science! You're using a rolling distribution;
you let your packages get /years/ out of date, and then you upgrade boot-
critical packages without either doing any research on what has changed in
the mean time, or AT LEAST reading the warnings! What do you EXPECT to
happen? Under such circumstances, I know what I'd expect. I'd expect a
tough time getting back up and running, when the system broke because I'd
effectively played Russian Roulette with my computer, with five bullets in
a six-shooter! Gentoo can put the warnings in the ebuild and cause them
to display, get mailed to you, whatever, depending on how you've
configured it, but you can lead a horse to water but can't make him drink,
and Gentoo can put the warnings there but can't make you read them.

This is especially true when you already know that the drives are SATAs
and appear as /dev/sd*, not /dev/hd*. There would be a /bit/ more excuse,
if you'd just upgraded legacy PATA drives, as the they are now taken care
of by libata as well by default, and switching from /dev/hd* to /dev/sd*.
But you already knew your drives were /dev/sd*, so why /on/ /earth/ were
you using /dev/hd* in your fstab, anyway? For the folks with PATA drives
who have been living under rocks and in caves for several years now,
there's at least /some/ explanation, since the switch to /dev/sd* could
take them by surprise (again, if they've been living under a rock or in a
cave, I'd not expect a responsible sysadmin who has been around to have
missed that), but you... you knew your drives were /dev/sd* already? Why
on /earth/ were you using /dev/hd* then?

> I ran into this a few weeks ago. I to have the old IDE hard drives. I
> had to switch to PATA which means my drives are now sd* instead of hd*.

As I said, at least there's /some/ excuse with PATA/IDE.

> I don't use LVM tho. I set LABELS on mine and use that to boot and
> mount the partitions where that are supposed to mount. It worked pretty
> well and since I'm using LABELS I can also boot the older kernels and
> hopefully any future kernels that come out.

Actually, that's the way I have mine setup now too, with labels. That
way, it shouldn't matter if the partition is on /dev/hda, /dev/md3, /dev/
sdz, or something else, mount and the kernel should be able to figure it
out.

> I *think* LVM can use LABELS to. If so, that would be my suggestion.
> That way you can move things around as needed and them still boot as
> they still be able to find your partitions.

Seconded.

The one thing that can be a bit confusing then, however, especially with
multiple layers such as mdraid, dmraid, lvm, etc, is keeping straight
which devices are which, when maintenance using the device nodes instead
of the labels is needed.

> So far, I have not been able to get Grub to see the LABELS. I just
> haven't been able to do much testing on it yet.

AFAIK (and this is why I replied here, instead of directly to the above
post), grub-1 (0.97-r*, called "legacy" and unsupported for years
upstream, even well before grub2's on-disk format stabilized, in that
regard they pulled a KDE, leaving the current actually working version
without support, while the new version was still way broken, tho luckily
in the grub case, the community was big enough that community patches have
continued to sustain grub-legacy over the gap, adding new features like gpt
partition support, ext4 filesystem support, etc, well after upstream
abandoned their stable code but years before the new version was even
generally usable, let alone production-ready) can't use labels. It's
/possible/ grub2 might, but I don't know for sure as I've not upgraded to
it yet.

> If LVM can work with this, it should be backward compatible
> with the kernels.

I don't believe lvm works with labels directly, because labels are a
file-system-level feature, and lvm is a below-file-system-level layer.
Neither does mdraid (mdadm), for much the same reason.

However, mdadm DOES allow device sequence change flexibility, because it
puts MORE than enough data in its medadata headers to easily identify the
mdraid devices on its own -- as long as you point it at the correct set of
devices. (If no DEVICE line, what it uses to configure where it scans, is
present, it scans devices listed in /proc/partitions, a sane default.)

FWIW, I ran lvm for awhile, but decided that now that mdraid handles
partitioned raid, there wasn't much need for it any longer, and what with
lvm on mdraid (partitions) on raw disk partitions, the complexity both of
keeping track of it all, AND of keeping enough of both the mdadm and lvm
administration commands in my head to properly fix things if something
went wrong... was getting dangerously high. As complex as it was, I was
thus more likely to make a critical data-loss mistake. As such, I decided
it was better to dump the lvm, and deal simply with partitioned RAID.
Unfortunately, I've forgotten enough about lvm since then that I don't
remember exactly what features it did have in this regard, but as I said,
I doubt it has label support because labels are a file-system-level
feature, and the filesystems go on lvm, not lvm on the filesystems. But I
expect it DOES have UID and scanning support.

FWIW2, as disks increase beyond the 2-T barrier, with legacy MBR style
partitioning reaching its limits at 2-T, the newer GPT (GUID Partitioning
Table, originally developed as part of EFI (Extensible Firmware Interface,
think Apple and Intel), but backward compatible with BIOS based machines
as well) is likely to take over. GPT has a number of advantages,
including keeping redundant copies at each end of the disk and checksums
for reliability and doing away with the primary/secondary/extended
partition distinction, but ALSO including a partition-level label-type
feature. Given that, as GPT becomes more common, it's very likely the
various above-partition-below-filesystem level tools and systems,
including mdraid/mdadm and lvm/devicemapper/dmraid, will grow support for
partition labels as well. Until that point, however, the much less human
readable UUID/GUID system is the closest it can get.

BTW (or FWIW3, if you prefer), the whole idea behind udev is that it's now
user customizable. You can make the devices show up either directly, or
via symlink, as whatever name you want. If you want to name your hard
drives after the planets, /dev/mercury instead of /dev/sda (or hda),
followed by venus, earth, mars... instead of sdb, sdc, sdd... that's
doable.

It is of course also doable to find and save the old udev hd*
compatibility rules, if you want, keeping them around for continued use.
That's even easier than devising your own rules, since they're pre-made.
Just find and save somewhere the file(s) that take care of that, before
doing the upgrade. You can read about it in the udev manpage if you like,
but the default rules location is /lib(64)?/udev/rules.d, so you'll
probably find them there (tho there might be a helper script that you need
to save as well), while the custom rules location is /etc/udev/rules.d, so
that's where you should copy them too.

Again, Gentoo has documentation on this, the udev guide. You can get as
deeply into it, designing as complex a ruleset doing who knows what, as
you want. As is normally the case with Gentoo, it's all up to you. But
again, if you want to just do upgrades without reading any warnings or
documentation, even when it's spit-out in ewarns in the upgrade itself,
well, I suggest you go looking for a different distribution, because
Gentoo wasn't designed as a babysitter, and really, there /are/ others
that better fit that bill.

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

Desktop problem with /dev/hda
 

On Fri, 2010-09-10 at 07:02 +0000, Duncan wrote:
> 2.6.32 is the current long-term-stable-support release. If I were running
> my kernels as long as you do, that's what I'd be upgrading to, because
> it'll be supported (and get security and bug patch support in further
> stable releases) for some time yet, not the 2.6.29 that's no longer
> upstream supported.
>
> I'd STRONGLY suggest you do whatever research you might wish to, to
> confirm what I just stated, and then then seriously consider 2.6.32.
> Either that, or go back to 2.6.27, because altho its support is about to
> end (again, unless someone else picks it up), it has been supported as a
> long-term-stable for quite some time now and has a lot more of the bugs
> worked out than 2.6.29 will ever get.

Well you're right about that. The current portage tree, in fact, has
2.6.34-r6 as the stable release.

I run a couple of small businesses, one of which (my music biz) requires
me to periodically do some traveling, so I'm away and pretty busy a lot.
My pattern has been to get my various Gentoo and Ubuntu systems into a
stable state and leave them, especially my desktop, since I'm often
critically strapped for time, and tinkering with Linux gets pushed to a
back burner.

I'll probably get kernel 2.6.34, update udev, and give it another shot.

--
Lindsay Haisley | "We have met the enemy, and it is us."
FMP Computer Services |
512-259-1190 | -- Pogo
http://www.fmp.com |

Desktop problem with /dev/hda
 

On Sat, 11 Sep 2010, Lindsay Haisley wrote:


I'll probably get kernel 2.6.34, update udev, and give it another shot.


This may have been mentioned already somewhere in the thread earlier,
but aside from the changes to udev, recent versions of the kernel have
also switched from the former behavior of just using Sata drivers for
real Sata drives and still providing the old ATA drivers for Pata, to
prefering Sata drivers for everything, even drives with Pata interfaces
(including DVD drives). The old Pata driver tree is still in the
kernel, but is now completely deprecated for just about everything now.


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.


--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky

Desktop problem with /dev/hda
 

Lindsay Haisley posted on Sat, 11 Sep 2010 12:44:06 -0500 as excerpted:

> On Fri, 2010-09-10 at 07:02 +0000, Duncan wrote:
>> 2.6.32 is the current long-term-stable-support release. If I were
>> running my kernels as long as you do, that's what I'd be upgrading to,
>> because it'll be supported (and get security and bug patch support in
>> further stable releases) for some time yet, not the 2.6.29 that's no
>> longer upstream supported.
>>
>> I'd STRONGLY suggest you do whatever research you might wish to, to
>> confirm what I just stated, and then then seriously consider 2.6.32.
>> Either that, or go back to 2.6.27, because altho its support is about
>> to end (again, unless someone else picks it up), it has been supported
>> as a long-term-stable for quite some time now and has a lot more of the
>> bugs worked out than 2.6.29 will ever get.
>
> Well you're right about that. The current portage tree, in fact, has
> 2.6.34-r6 as the stable release.
>
> I run a couple of small businesses, one of which (my music biz) requires
> me to periodically do some traveling, so I'm away and pretty busy a lot.
> My pattern has been to get my various Gentoo and Ubuntu systems into a
> stable state and leave them, especially my desktop, since I'm often
> critically strapped for time, and tinkering with Linux gets pushed to a
> back burner.
>
> I'll probably get kernel 2.6.34, update udev, and give it another shot.

But note that 2.6.34 isn't a long-term-support kernel either, and will
only have a relatively few updates (until shortly after 2.6.36 is
released, and it's on rc3 or 4 already...). Given how seldom you change
kernels, I expect you really do want the latest long-term-support version,
2.6.32.

...

While leaving updates that long isn't me, I understand how it can be for
some users (and have put off updates myself recently, uncharacteristically
for me for weeks at a time, for this very reason). The point I was trying
to get across is that if you are such a user (and really, regardless,
whether you are or not), it's very critical that you read the news items
if there are any before doing your updates (portage will tell you so if
you do an ask or pretend; you can list and read them using eselect news
<whatever>), and that you read and follow-thru on the ewarns, which
portage by default displays again after the emerge is finished and which
you can configure to be mailed to you or logged, etc, before you consider
your upgrade done. If you fail to do so, especially for boot-critical
packages like udev, it's not a question of IF, but WHEN, such an update
WILL break your system. Unfortunately, you just found that out the hard
way.

If you don't have time for reading those, you don't have time for the
update, because you can't consider it done until you do, and follow thru,
and failing to do so is risking spending a lot MORE time figuring out what
broke and how to fix it, when things inevitably DO break, because the
followups weren't done. As I said, skipping the warnings, it's not a
question of if, but when, and just how bad the breakage is going to be and
how long it'll take to figure out and resolve the problem, so skipping
them really is NOT a viable option.

I wish there were some way to really drum this into every Gentoo user's
head when they started, so they never ended up having to learn it the hard
way, as you did. But as they say, if wishes were fishes...

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

Desktop problem with /dev/hda
 

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.

I have rather a conflict here, since I already have a /dev/sda.

Is there a HOWTO for using libata-supported kernel components, and
configuring them in the kernel? The MB has an ICH5 controller hub,
which I assume handles the PATA IF. lspci shows:

IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)

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?

--
Lindsay Haisley | "The difference between a duck is because
FMP Computer Services | one leg is both the same"
512-259-1190 | - Anonymous
http://www.fmp.com |

Desktop problem with /dev/hda
 

On Sat, 2010-09-11 at 23:13 +0000, Duncan wrote:
> If you don't have time for reading those, you don't have time for the
> update, because you can't consider it done until you do, and follow thru,
> and failing to do so is risking spending a lot MORE time figuring out what
> broke and how to fix it, when things inevitably DO break, because the
> followups weren't done. As I said, skipping the warnings, it's not a
> question of if, but when, and just how bad the breakage is going to be and
> how long it'll take to figure out and resolve the problem, so skipping
> them really is NOT a viable option.

Duncan, you're a good man, and have helped me before. I have 14 news
items on this box, of which I've only read 1. None of them deal with
libata and the switch in the kernel from PATA drivers to SATA with the
change of device names, etc. required to support this.

> I wish there were some way to really drum this into every Gentoo user's
> head when they started, so they never ended up having to learn it the hard
> way, as you did. But as they say, if wishes were fishes...

You know, I set up my Gentoo boxes - 2 commercial servers and a desktop
box - over 5 years ago. Gentoo was a lot simpler then. There were no
eselect news items to read because there was no eselect news. There was
also no decent system to read the emerge notes, so Eldad Zack and I
wrote one. I've had to learn a lot of stuff "the hard way" but as the
years go by I have less and less patience with having to get under the
hood and tinker. I'm kinda stuck with what I have. My servers are
running mysql 5.0. If I took them off line to upgrade everything to
mysql 5.1, every system on the boxes on which my customers depend would
break - mail service, DNS, SpamAssassin, billing, to mention a few, and
these would be down for who knows how long. I'm almost 70 years old.
I'll probably sell my business and let someone else worry about this
crap before I get everything truly up-to-date.

As far as the desktop system goes, I'll probably build a 2nd box, maybe
running another distribution, and migrate stuff to it incrementally. My
time and my sanity have value, and doing this may be less costly, in the
long run, than trying to hack this 5-year old box and being without a
desktop (and my company's billing system, and my email, and my web
development tools, etc. etc.) until I get it figured out.

Enough of this geezer-rant. Peace and love to everyone in these crazy
times. I mean it!

--
Lindsay Haisley | "Never expect the people who caused a problem
FMP Computer Services | to solve it." - Albert Einstein
512-259-1190 |
http://www.fmp.com |

Desktop problem with /dev/hda
 

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

Desktop problem with /dev/hda
 

On Sat, 11 Sep 2010, Lindsay Haisley wrote:


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.

I have rather a conflict here, since I already have a /dev/sda.

Is there a HOWTO for using libata-supported kernel components, and
configuring them in the kernel? The MB has an ICH5 controller hub,
which I assume handles the PATA IF. lspci shows:

IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)

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?


If you go through the list of drivers in the Sata section, toward the
second half of the list, there are Pata drivers. They used to be
deprecated, but now they're the only ones that are supported. You just
need to find the Pata drivers (in the Sata section) that correspond to
what you've got (you'll probably have to look around a bit), and then
turn off the entire old Pata section. There should probably be a Pata
driver in the new Sata section though that handles Intel PIIX chipset;
it's pretty common.


The danger that will make you want to keep a rescue CD handy is that
it's hard to predict how your devices are going to get enumerated at
bootup under these new semantics, or to know whether it will match what
you've got in your fstab. If you need a good rescue CD though, I'd
recommend System Rescue CD (http://www.sysresccd.org/), which is based
on Gentoo and handles about anything.


--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky