Mailing List Archive

Hi,

This is due to ATA/ATAPI (DEPRECATED) being disabled in newer kernels,
replaced by Serial ATA and Parallel ATA drivers.

Make sure you enabled this support properly.

In my case that happened to me as well, on a remote computer, which was my
mother's box...

Anyway, in fstab /dev/sdXX shoud work, at least I made this change on a
couple of machines and that went fine.

Cheers,
JM

On Sun, Mar 20, 2011 at 4:46 AM, Lindsay Haisley <fmouse-gentoo@fmp.com>wrote:

> I'm caught between a rock and a hard place.
>
> I've been running this desktop box using kernel 2.6.23-gentoo-r3 and
> have come to the point at which there are too many dependencies and
> reverse dependencies, so I _have_ to upgrade to kernel 2.6.29-gentoo-r5
> and have been unable to bring the system up in the new kernel. Here's
> what's happening.
>
> The newer kernel requires a newer version of udev, which I emerged. The
> system came up with a root device of some sort mounted, I think in
> single-user mode, but couldn't mount other devices.
>
> So I changed the main drive designations to UUID's in /etc/fstab,
> re-emerged the newer udev, and tried again. This time I got a message
> that the kernel needed a root parameter at boot time. It seems that all
> my /dev/hda? drives have been renamed /dev/sda? so I set gave
> "root=/dev/sda4" as a kernel parameter and got a little further. After
> "Checking root filesystem" in the boot sequence, I got a message that
> the UUID for the root filesystem wasn't understood in /etc/fstab.
>
> So I set the root filesystem in /etc/fstab to /dev/sda4, and got the
> same error - that "/dev/sda4" was not understood either, although the
> kernel seemed to understand this just fine as a boot parameter, and once
> again, I'm dumped into a very limited single-user mode.
>
> So I'm stuck! I had to boot from a rescue disk, back-version to
> udev-141 and revert to kernel 2.6.23-gentoo-r3 to get my desktop back.
>
> What do I need to put into /etc/fstab to satisfy the kernel? I need to
> move forward with this, but I need my desktop system to run my business.
> Any _real_ suggestions will be welcome. Please be aware that I'm no
> Linux novice, so don't give me novice advice. I've been building,
> running, and getting paid to admin Linux systems since 1995.
>
> --
> Lindsay Haisley | "Everything works if you let it"
> FMP Computer Services | (The Roadie)
> 512-259-1190 |
> http://www.fmp.com |
>
>
>


--
Jean-Marc

Please send us your `emerge --info`, /etc/fstab, grub/lilo/smthng
config and kernel config for the 2.6.29.

By the way, why not gentoo-sources-2.6.36-r5? I hope you have a good
reason to run a system as ancient as that. Your system is swarming with
widely known security holes. I suppose it's theoretically possible to
have a desktop protected by some special means from all the real threats
an actively used desktop is facing, but I wonder if you use any such
means. Also, by upgrading to a little less ancient versions than 2.6.29
you won't have the same situation like now boomerang back at you in the
near future.

-rz


Lindsay Haisley (Sat, 19 Mar 2011 23:46:06 -0500):
> I'm caught between a rock and a hard place.
>
> I've been running this desktop box using kernel 2.6.23-gentoo-r3 and
> have come to the point at which there are too many dependencies and
> reverse dependencies, so I _have_ to upgrade to kernel 2.6.29-gentoo-r5
> and have been unable to bring the system up in the new kernel. Here's
> what's happening.
>
> The newer kernel requires a newer version of udev, which I emerged. The
> system came up with a root device of some sort mounted, I think in
> single-user mode, but couldn't mount other devices.
>
> So I changed the main drive designations to UUID's in /etc/fstab,
> re-emerged the newer udev, and tried again. This time I got a message
> that the kernel needed a root parameter at boot time. It seems that all
> my /dev/hda? drives have been renamed /dev/sda? so I set gave
> "root=/dev/sda4" as a kernel parameter and got a little further. After
> "Checking root filesystem" in the boot sequence, I got a message that
> the UUID for the root filesystem wasn't understood in /etc/fstab.
>
> So I set the root filesystem in /etc/fstab to /dev/sda4, and got the
> same error - that "/dev/sda4" was not understood either, although the
> kernel seemed to understand this just fine as a boot parameter, and once
> again, I'm dumped into a very limited single-user mode.
>
> So I'm stuck! I had to boot from a rescue disk, back-version to
> udev-141 and revert to kernel 2.6.23-gentoo-r3 to get my desktop back.
>
> What do I need to put into /etc/fstab to satisfy the kernel? I need to
> move forward with this, but I need my desktop system to run my business.
> Any _real_ suggestions will be welcome. Please be aware that I'm no
> Linux novice, so don't give me novice advice. I've been building,
> running, and getting paid to admin Linux systems since 1995.
>

Lindsay Haisley posted on Sat, 19 Mar 2011 23:46:06 -0500 as excerpted:

> I'm caught between a rock and a hard place.
>
> I've been running this desktop box using kernel 2.6.23-gentoo-r3 and
> have come to the point at which there are too many dependencies and
> reverse dependencies, so I _have_ to upgrade to kernel 2.6.29-gentoo-r5
> and have been unable to bring the system up in the new kernel. Here's
> what's happening.

You're still running 2.6.23 on a /desktop/? I can see how it could be
argued for a server that had /years/ of uptime, but for a desktop... I
/really/ think you should upgrade a bit more often (as it would seem
you're unfortunately finding out)...

> The newer kernel requires a newer version of udev, which I emerged. The
> system came up with a root device of some sort mounted, I think in
> single-user mode, but couldn't mount other devices.
>
> So I changed the main drive designations to UUID's in /etc/fstab,
> re-emerged the newer udev, and tried again. This time I got a message
> that the kernel needed a root parameter at boot time. It seems that all
> my /dev/hda? drives have been renamed /dev/sda? so I set gave
> "root=/dev/sda4" as a kernel parameter and got a little further.

Yes. The old IDE subsystem used hdX device names. The newer libata based
subsystem handles both PATA and SATA, using the traditionally SCSI device
names of sdX instead of the traditionally IDE names of hdX.

Of course, that's years'-old news by now, for anyone taking the "rolling"
in rolling update at anything close to face value... Seriously. If you
/are/ going to let things get that outdated, I'd recommend something like
CentOS. At least there, such big updates so far apart are semi-standard,
and thus, both the distribution itself and its community are better
equipped to handle them.

Gentoo, OTOH, is a /rolling/ /update/ distribution. They actually find it
necessary to warn people not to (routinely) sync more than once a day, and
updating daily to perhaps at the outside monthly, really is how it works
best. I believe you've seen this "sermon" before so I'll keep it short,
but honestly, I'm not just saying this, if you're not going to go rolling
update with it, and rolling update is NOT for everybody, you really
/should/ reevaluate whether Gentoo is the really the best matching choice
for your needs. An "impedance mismatch" of that magnitude may be possible
to work around, but just because it's possible doesn't mean it's the most
efficient choice available, for sure.

(The two following paragraphs are recent personal experience with an
8-month-out update. Skip if you wish...

FWIW, I just upgraded my netbook from about 8 months out, kde 4.4.5,
skipping 4.5 entirely, to 4.6.1. I was able to do it because I understand
reasonably well both the kernel and the Gentoo distribution as well as the
hardware, following developments quite closely even when I'm not actually
updating, AND because I kept the usual incremental rolling updates on my
workstation during the period, so I'd done all except the hardware-
specific updates before, just not all at once, but I'll tell you what, I'd
have a whole lot rather kept it updated at least every 2-3 months maximum.

... Further, while it's probably fair to say it was easier for me to do
the 8-month update than to backup /etc, /home and the kernel config, and
start from a clean stage-3 tarball, it wasn't so by much, and for people
who don't keep such close track of Gentoo and Linux developments in
general and/or who hadn't been regularly updating other systems so as to
have gone thru most of the updates already, just not all at once, starting
from that clean stage-3 probably would have been easier! And I can say
that as I recently helped a friend install from a stage-3, too, so I've
done both recently. Thus, I now have personal experience to confirm what
has been previously stated in other threads, that a six-month update is
approaching the outer limits of practicality for an ordinary Gentooer, and
that somewhere between that six months and a year, installing from a fresh
stage-3 does become the most practical option.)

> After
> "Checking root filesystem" in the boot sequence, I got a message that
> the UUID for the root filesystem wasn't understood in /etc/fstab.

> So I set the root filesystem in /etc/fstab to /dev/sda4, and got the
> same error - that "/dev/sda4" was not understood either, although the
> kernel seemed to understand this just fine as a boot parameter, and once
> again, I'm dumped into a very limited single-user mode.
>
> So I'm stuck! I had to boot from a rescue disk, back-version to
> udev-141 and revert to kernel 2.6.23-gentoo-r3 to get my desktop back.
>
> What do I need to put into /etc/fstab to satisfy the kernel? I need to
> move forward with this, but I need my desktop system to run my business.
> Any _real_ suggestions will be welcome. Please be aware that I'm no
> Linux novice, so don't give me novice advice. I've been building,
> running, and getting paid to admin Linux systems since 1995.

Do you run an initrd/initramfs? (AFAIK you do if you use genkernel, since
it pretty much compiles everything as modules, putting what it thinks
necessary to load the real-root in the initrd/initramfs.)

I'll skip the detail on init(rd|ramfs) both because I don't use it myself
and because as you mention, you /aren't/ a novice, so if you do use one,
you can probably tell me more about how it works than I can tell you, but..

Either...

1) it's loading the kernel and dropping you in the initrd/initramfs,
because it can't load real-root,

OR

2) It's loading root initially (either you don't have an initrd/initramfs
or it gets past that), which normally defaults to read-only mode, and is
failing when it tries to do the initial rootfs fsck and/or when it tries
to do the remount read/write, which occurs just after that.

In either case, since you specifically mention that you get a limited
single-user-mode, NOT a kernel panic as it tries to read the initial root
(whether that's an initrd/initramfs or the real root), the kernel
definitely DOES know how to read and mount that initial root and drop you
into /some/ sort of user mode, even if limited single-user.

(It's worth noting here that one of the issues I experienced with that
8-month update above, was that somehow, when I updated the kernel from
2.35-rc6-gitsomething, what I'd been running before, to 2.6.38, what I'm
running now on both workstation and netbook, the config option for my SATA
chipset vanished when I did make oldconfig, and my first kernel rebuild
panicked when it couldn't find root. I'm familiar enough with the
kernel's boot messages and the hardware that I realized that it couldn't
see sda at all, which meant either the hardware was dying and that didn't
seem to be the case, or it wasn't loading the driver, so I deduced the
problem almost immediately, and sure enough, when I checked the kernel
config, it wasn't building that driver (I don't use modules, only the
options I need, built-in), so change the option to build it, rebuild and
install the kernel, and try again. It worked once it had the driver for
the sata controller, but the point is, I use all built-ins and no init(rd|
ramfs), so it kernel panicked before loading any userspace at all.)

If you do NOT use an initr*, the fact that it's loading even the single-
user userspace indicates that it not only properly loads the PATA driver
and detects the hardware, but that it ALSO groks the rootfs and loads it
read-only. In that case, your problem really is one with fsck/mount/fstab
or the scripts that invoke them.

OTOH, if you DO use an initr*, the first thing to determine is whether
it's getting past that and dropping you into the real-root, in which case
you have the same as above fsck/mount/fstab or script issues to look at,
*OR*, whether you're getting dropped into that limited userspace while
it's still initr*-based-only, in which case your problem is with the
initr*, NOT with the real-root that the system later pivot-root-s to.

Given the info you posted, I'll predict that the most likely case, and I
state this again with the caveat that I don't use initr* personally so
don't know that much about it, is that you DO use an initr*, and are stuck
in it, as it either doesn't have the correct kernel PATA driver and thus
can't see the drive at all, or it has that but is missing the correct
filesystem module, so it sees the drive but can't understand the
filesystem you're pointing it at.

From what I've /read/ about initr*, back when initrds were the norm, the
most common problem here was that either the updated kernel entry line
still pointed at the old initrd, or that the initrd hadn't been updated at
all. In either case, the actually loaded initrd had the modules for the
old kernel, which the new kernel would refuse to load.

Initramfs made that problem much less common as the initramfs is now
appended to the end of the kernel file making it far more difficult to
have a kernel/initr* mismatch, but the same effect sometimes happens, if
the new kernel build doesn't build the appropriate modules or for whatever
reason they're not included in the initramfs.

But beyond that you'll need to find someone with more initr* knowledge to
help if it's an initr* issue, which I suspect it is. It's a reasonably
common problem, but one I have no experience with and don't know the
details of the fix on.

If you're actually getting your real-root loaded, either because you don't
use an initr* or because it's correct and you're successfully getting the
pivot-root, then as I said, it would appear to be a problem with fsck,
mount, fstab, or possibly the initscripts invoking them. However, those
are less common and there's not enough data in the original post to really
go further with it at this point.

But I bet (and hope) it's an initr* problem... simply because those are
most common, and normally easy to solve -- simply make sure you're loading
the one corresponding to the new kernel and that it has the correct
drivers and config...

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

On Sun, 20 Mar 2011, Jean-Marc Beaune wrote:

> This is due to ATA/ATAPI (DEPRECATED) being disabled in newer kernels,
> replaced by Serial ATA and Parallel ATA drivers.
>
> Make sure you enabled this support properly.
>
> In my case that happened to me as well, on a remote computer, which was my
> mother's box...
>
> Anyway, in fstab /dev/sdXX shoud work, at least I made this change on a
> couple of machines and that went fine.

Yes, I went through this also awhile back. All your drivers should now
come from the Sata section, both the Sata drivers for your hard drives,
plus the Pata drivers for any Pata DVD drives you may have. There are
now Pata support drivers living in the Sata section. You should turn
off the toggle for the entire old Pata driver section in menuconfig.
If you have only Pata drives, you should just use the Pata drivers from
the Sata section by themselves. No need for anything in the old Pata
section in any case anymore.

The newer Sata subsystem Pata drivers had been included before in the
kernel for a long time as deprecated drivers for people to beta test,
and the regular Pata drivers were recommended for use. Now it's
reversed -- the Pata drivers in the Sata section are recommended, and
the old Pata drivers from the Pata section are deprecated...expecially
because they don't work anymore with current versions of udev!

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

On Sun, 2011-03-20 at 09:50 +0100, Roman Zilka wrote:
> By the way, why not gentoo-sources-2.6.36-r5? I hope you have a good
> reason to run a system as ancient as that. Your system is swarming with
> widely known security holes.

Yes, I have a good reason for this, and I'll be responsible for security
on the box, which I'm well able to do. Security, and the relative
antiquity of the portage tree are not issues for which I'm seeking
advice, so your observations are totally beside the point, and not
particularly welcome. I'm well aware of both issues.

The challenge here is to get the system to boot with the newer kernel
and version of udev which I cited in my previous post.

/etc/fstab has been edited several times, as I noted in my post. The
kernel, udev and /etc/fstab have been now been reverted, as I also noted, so
I could get the desktop working. Considering that, posting any of the
information you've asked for would probably be useless.

Roman, if you don't have any useful insights based on the information I
already posted, then please don't post on thread and leave it to others
who may.

Having said this, I'll ask you one question:

> Also, by upgrading to a little less ancient versions than 2.6.29
> you won't have the same situation like now boomerang back at you in the
> near future.

Can you cite a source or sources for this assertion? Is there a known
problem with kernel 2.6.29, or the portage tree which spec'd that
kernel? Is there any discussion, bug report, or anything that you can
cite noting that this was a known problem at one point and addressed at
a later date?

In almost every case, I've found that people who lecture me online about
my system admin practices don't really have a handle on the issue about
which I'm writing. Please prove me wrong :-)

--
Lindsay Haisley |"What if the Hokey Pokey really IS all it
FMP Computer Services | really is about?"
512-259-1190 |
http://www.fmp.com | -- Jimmy Buffett


--
Lindsay Haisley |"Windows .....
FMP Computer Services | life's too short!"
512-259-1190 |
http://www.fmp.com | - Brad Johnston

On Sun, 2011-03-20 at 08:24 +0000, Jean-Marc Beaune wrote:
> This is due to ATA/ATAPI (DEPRECATED) being disabled in newer kernels,
> replaced by Serial ATA and Parallel ATA drivers.
>
> Make sure you enabled this support properly.
>
> In my case that happened to me as well, on a remote computer, which
> was my mother's box...
>
> Anyway, in fstab /dev/sdXX shoud work, at least I made this change on
> a couple of machines and that went fine.

Jean-Marc, thanks. This gives me a bit of insight.

I've been compiling kernels for this box for some time, carrying over
the .config file between kernel versions and updating them. Last night
I built IDE functionality as a module (it was previously compiled into
the kernel, as per my carried-over .config files) thinking that I would
simply not load it at run-time. As I noted in my post, while the the
kernel recognized "root=/dev/sda4" as a kernel param, the boot process
crashed with a note that "/dev/sda4" wasn't recognized. It's entirely
possible that this module got auto-loaded, or that there's some other
anomaly in my kernel config that's throwing things off.

My next step is to completely rebuild the kernel, using the config built
into the distributed kernel source, making only the necessary mods for
the box's hardware needs. I'll find a time window during the next few
days to work on this.

--
Lindsay Haisley |"Windows .....
FMP Computer Services | life's too short!"
512-259-1190 |
http://www.fmp.com | - Brad Johnston

On Sun, 2011-03-20 at 09:32 +0000, Duncan wrote:
> Gentoo, OTOH, is a /rolling/ /update/ distribution. They actually find it
> necessary to warn people not to (routinely) sync more than once a day, and
> updating daily to perhaps at the outside monthly, really is how it works
> best. I believe you've seen this "sermon" before so I'll keep it short,
> but honestly, I'm not just saying this, if you're not going to go rolling
> update with it, and rolling update is NOT for everybody, you really
> /should/ reevaluate whether Gentoo is the really the best matching choice
> for your needs. An "impedance mismatch" of that magnitude may be possible
> to work around, but just because it's possible doesn't mean it's the most
> efficient choice available, for sure.

Duncan, thank you. I'm well aware of the advantages and disadvantages
of Gentoo's "rolling update" distribution design, and really appreciate
the advantages. My problem isn't knowledge, of which I have enough, but
time. Maintaining a Gentoo system is a relatively time consuming
activity, and I'm spread extremely thin these days. This problem box
has been running Gentoo since 2004, but my work and priorities on my
time have changed over the years and it's probably time to move on.
Gentoo has gotten a lot more complex since then - arguably better, but
certainly more time-consuming to maintain.

In the meantime, I need to address the kernel | fstab | udev issue here.
Insights and suggestions to address _this_ problem would be most
helpful. Lectures on the age of my system, my qualifications as an
admin for my own desktop, or my continued us of Gentoo as a desktop
distribution are not helpful.

--
Lindsay Haisley |"Windows .....
FMP Computer Services | life's too short!"
512-259-1190 |
http://www.fmp.com | - Brad Johnston

On Sun, 2011-03-20 at 11:50 -0500, Lindsay Haisley wrote:
> This problem box
> has been running Gentoo since 2004, but my work and priorities on my
> time have changed over the years and it's probably time to move on.

To be a bit more precise here, I'm actively working on replacing this
box, and will be running a Linux distribution on it other than Gentoo.
But in the meantime, I do need to solve the problem about which I
posted.

--
Lindsay Haisley |"Friends are like potatoes.
FMP Computer Services | If you eat them, they die"
512-259-1190 |
http://www.fmp.com | - Aaron Edmund

Lindsay Haisley posted on Sun, 20 Mar 2011 13:48:43 -0500 as excerpted:

> On Sun, 2011-03-20 at 11:50 -0500, Lindsay Haisley wrote:
>> This problem box has been running Gentoo since 2004, but my work and
>> priorities on my time have changed over the years and it's probably
>> time to move on.
>
> To be a bit more precise here, I'm actively working on replacing this
> box, and will be running a Linux distribution on it other than Gentoo.
> But in the meantime, I do need to solve the problem about which I
> posted.

I appreciate that you /have/ decided to ultimately switch, and obviously
believe it best or I'd have not recommend it.

I also appreciate that you need a solution for now. That's what I suspect
I may have provided (at least to a point) further down that post, which
you may not have read given the order.

I was hoping to read all these replies and have you tell me whether I was
on the right track or not, answering the question about initrd/initramfs
so we could go from there if need be. However, I don't see that answer,
which suggests you didn't read that far down my post, for which I can't
really blame you.

But you can always go back and do it now... =:^)

Briefly repeating so you can see if it's worth your trouble going back to
get the details.

If the kernel could not load its initial root, be that initr* or the real-
root, it'd fail to load any userspace at all as it couldn't get to it,
panicking instead when it couldn't get to a root at all. (I know this
from experience.)

Thus, that it's getting even a /limited/ userspace indicates it's getting
to it's initial root. That's a very significant point.

The question from there is whether that limited userspace is loading from
the initrd/initramfs if you have one, indicating it's not successfully
doing the initial real-root mount and pivot-root from the initr*, taking
you down one path toward a solution (missing or incorrect drivers in the
initr* or wrong initrd), or whether it's loading the real-root (as just
getting to userspace at all indicates if you don't have an initr*), thus
indicating that it has the necessary drivers (both pata and fs) to do so,
and the problem is later, with the fsck or remount, taking you down a
different path toward a solution (userspace issue).

If that sounds useful, check the earlier post for more. If it doesn't,
don't bother, as that's what I was detailing in the earlier post.

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

> /etc/fstab has been edited several times, as I noted in my post. The
> kernel, udev and /etc/fstab have been now been reverted, as I also noted, so
> I could get the desktop working. Considering that, posting any of the
> information you've asked for would probably be useless.

OK, so be it, fstab is not that important.

> Roman, if you don't have any useful insights based on the information I
> already posted, then please don't post on thread and leave it to others
> who may.

I may have useful insights that are different from the insights posted
previously by other people. But I need your `emerge --info` and kernel
conf for that first. To give you a hint of explanation: I need the
kernel conf to look for whatever may be wrong in there. There's no
point in sending you a working conf for my (i.e., different) machine -
there's plenty of those lying around the net, as we both know. I assume
you have either already tried one of those or simply don't want to use
one for some reason. Thus, it's possible that you keep making a
recurring mistake while modifying default / borrowed / your own old
configs. And I need to see your conf to discover such potential
mistakes. As for `emerge --info`, it may uncover problems relevant in
this case too.

Please, cooperate with those whom you'd asked for help. Writing these
several paragraphs worth of e-mail text as a reply was a waste of time
for you - it clearly hasn't produced any help at all regarding your
booting issue. On the other hand, sending me what I'd asked for right
away would not only eat up much less of your time, it might have
yielded a solution by now. I suppose you're asking for help because you
understand that others may be more knowledgeable than yourself.

> > Also, by upgrading to a little less ancient versions than 2.6.29
> > you won't have the same situation like now boomerang back at you in the
> > near future.
>
> Can you cite a source or sources for this assertion?

The source is the very reality of change of things in the world over
time. Software evolves and because hardly anything in nature has
infinite duration, it is only a matter of time before compatibility of
udev (or something else) with the 2.6.29 ends. In fact, this is true
for any two pieces of software that coexist, not just the
kernel+something, of course.

> Is there a known
> problem with kernel 2.6.29, or the portage tree which spec'd that
> kernel?

There are so many known problems with that kernel that it'd take me a
lifetime to remember and copy them all. See:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.3?*

And some of those are relatively serious security holes and it'd take a
really special handling of the system to avoid them. And I'm talking
about handling that'd probably render an Internet-connected desktop box
with a web browser unusable. I'm not gonna google those specific ones
for you, we don't need that to get ahead; every active admin will
remember them.

And yes, Gentoo devs deem 2.6.29 dangerous too - that's why it isn't in
the current Portage tree at all (vanilla-sources and gentoo-sources).
Kernel devs themselves deem it dangerous and they don't maintain that
branch anymore. Of what's maintained (in terms of security patches),
2.6.27 and 2.6.32 are nearest to 2.6.29. And I wouldn't expect at least
one of them to linger around for a very long time.

> In almost every case, I've found that people who lecture me online about
> my system admin practices don't really have a handle on the issue about
> which I'm writing. Please prove me wrong :-)

I suppose one can say I've done just that, having written what I've
written. At least I hope did so in a sensitive way. There's no need to
defend your admin skills in case you happen to feel offended by
something above. Why is there no need? Because failing in an honest
effort is not a reason for disregard for a human being. So there's
actually no harm for you from that.

Well, in fact, it is a reason for disregard for a few people, but let's
not have our lives spoiled by those.:)

-rz

> Well, in fact, it is a reason for disregard for a few people, but let's
> not have our lives spoiled by those.:)

*aehm* Sorry for being ambiguous here. In other words: there are a few
people who take it as a reason for disregard. But let's not have our
lives spoiled by those said few people.:)

-rz

Evidently your not all that good a sysadmin as you claim to be and you surely can't admin a Gentoo box. The solution is easy, you are making it hard. Wipe your drive and install ubuntu.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Lindsay Haisley <fmouse-gentoo@fmp.com>
Date: Sun, 20 Mar 2011 11:08:37
To: <gentoo-desktop@lists.gentoo.org>
Reply-to: gentoo-desktop@lists.gentoo.org
Subject: Re: [gentoo-desktop] System problems

On Sun, 2011-03-20 at 09:50 +0100, Roman Zilka wrote:
> By the way, why not gentoo-sources-2.6.36-r5? I hope you have a good
> reason to run a system as ancient as that. Your system is swarming with
> widely known security holes.

Yes, I have a good reason for this, and I'll be responsible for security
on the box, which I'm well able to do. Security, and the relative
antiquity of the portage tree are not issues for which I'm seeking
advice, so your observations are totally beside the point, and not
particularly welcome. I'm well aware of both issues.

The challenge here is to get the system to boot with the newer kernel
and version of udev which I cited in my previous post.

/etc/fstab has been edited several times, as I noted in my post. The
kernel, udev and /etc/fstab have been now been reverted, as I also noted, so
I could get the desktop working. Considering that, posting any of the
information you've asked for would probably be useless.

Roman, if you don't have any useful insights based on the information I
already posted, then please don't post on thread and leave it to others
who may.

Having said this, I'll ask you one question:

> Also, by upgrading to a little less ancient versions than 2.6.29
> you won't have the same situation like now boomerang back at you in the
> near future.

Can you cite a source or sources for this assertion? Is there a known
problem with kernel 2.6.29, or the portage tree which spec'd that
kernel? Is there any discussion, bug report, or anything that you can
cite noting that this was a known problem at one point and addressed at
a later date?

In almost every case, I've found that people who lecture me online about
my system admin practices don't really have a handle on the issue about
which I'm writing. Please prove me wrong :-)

--
Lindsay Haisley |"What if the Hokey Pokey really IS all it
FMP Computer Services | really is about?"
512-259-1190 |
http://www.fmp.com | -- Jimmy Buffett


--
Lindsay Haisley |"Windows .....
FMP Computer Services | life's too short!"
512-259-1190 |
http://www.fmp.com | - Brad Johnston

On Sun, 2011-03-20 at 23:59 +0000, eamjr56@gmail.com wrote:
> Evidently your not all that good a sysadmin as you claim to be and you
> surely can't admin a Gentoo box. The solution is easy, you are making
> it hard. Wipe your drive and install ubuntu.

<LOL!> As a matter of fact, my new desktop box _will_ be running Ubuntu
desktop. I'm not out to prove my Linux cajones by making work for
myself that I don't need ;-) And I'm not going to insult everyone on
this forum by running down Gentoo, which has displayed some absolutely
brilliant programming skills on the part of many of the developers. I
expect the same respect in return, eamjr56.

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

On Mon, 2011-03-21 at 00:10 +0100, Roman Zilka wrote:
> > /etc/fstab has been edited several times, as I noted in my post. The
> > kernel, udev and /etc/fstab have been now been reverted, as I also noted, so
> > I could get the desktop working. Considering that, posting any of the
> > information you've asked for would probably be useless.
>
> OK, so be it, fstab is not that important.

Actually, /etc/fstab has been central to the problem, since the system
seems to be unable to interpret it during the boot process, although the
kernel correctly interprets the same drive spec when it's on the kernel
cmd line in menu.lst.

> > Roman, if you don't have any useful insights based on the information I
> > already posted, then please don't post on thread and leave it to others
> > who may.
>
> I may have useful insights that are different from the insights posted
> previously by other people. But I need your `emerge --info` and kernel
> conf for that first. To give you a hint of explanation: I need the
> kernel conf to look for whatever may be wrong in there.

What I'll do is this, Roman. I've emerged the linux-2.6.36-gentoo-r5
kernel and built it with the _stock_ Gentoo settings. I'll add the
specific drivers for my hardware, such as my NIC and dual sound cards,
rebuild the kernel again and take another shot at it when my time
allows. If the problem persists, _then_ my kernel .config may be a
candidate for more eyes to look at than mine.

As you kind of point out, it really doesn't make sense to work with
trying to whip into shape a kernel that's no longer even in the portage
tree, and probably shouldn't be used in any event, and which has been
configured with my legacy .config setup.

This will take some of the variables out of the problem and if
necessary, perhaps we can look at the situation more cleanly.

> There's no
> point in sending you a working conf for my (i.e., different) machine -
> there's plenty of those lying around the net, as we both know. I assume
> you have either already tried one of those or simply don't want to use
> one for some reason.

I'm going to start with the _stock_ Gentoo kernel config, which should
at very least bring up the drives. If I can get the drives and boot
process to work, then I can add modules and facilities after that.

> Thus, it's possible that you keep making a
> recurring mistake while modifying default / borrowed / your own old
> configs.

This is absolutely true, as noted above.

> And I need to see your conf to discover such potential
> mistakes. As for `emerge --info`, it may uncover problems relevant in
> this case too.

"emerge --info" is the the stock Gentoo system profile, and I'll be
happy to share it, but in this case I'm looking at what's almost a
"pre-Gentoo" issue, involving the kernel and the boot-up.

> Please, cooperate with those whom you'd asked for help. Writing these
> several paragraphs worth of e-mail text as a reply was a waste of time
> for you - it clearly hasn't produced any help at all regarding your
> booting issue.

Taking the desktop system off-line, re-emerging udev, bringing it up
into its failure mode with a newer kernel and pulling the necessary
pieces together, then backing out and putting everything back so the
system is actually fairly usable is a major hassle. I have had _zero_
time to work on this problem since I posted this morning, but will be
able to take another run at it this evening, hopefully. Writing is no
effort for me, and doesn't disable my desktop ;)

> On the other hand, sending me what I'd asked for right
> away would not only eat up much less of your time, it might have
> yielded a solution by now. I suppose you're asking for help because you
> understand that others may be more knowledgeable than yourself.

We are all have different skill and knowledge sets, and sometimes, as
everyone has found out, the very process of organizing the presentation
of a problem to others leads one to a solution.

> > Can you cite a source or sources for this assertion?
>
> The source is the very reality of change of things in the world over
> time. Software evolves and because hardly anything in nature has
> infinite duration,

I was hoping for something a little less nebulous ;-)

> And some of those are relatively serious security holes and it'd take a
> really special handling of the system to avoid them. And I'm talking
> about handling that'd probably render an Internet-connected desktop box
> with a web browser unusable.

This desktop box is on an RFC-1918 masqueraded network. It has zero
exposure to the Internet, except insofar as the firewall will permit
traffic from related and established connections, as per the firewall
NAT rules. The only other person on the LAN is my sweetie, and as far
as I know I can trust her not to black-hat hack my desktop system :-)
All my professional work is done via VPNs to my client's systems.

> And yes, Gentoo devs deem 2.6.29 dangerous too - that's why it isn't in
> the current Portage tree at all (vanilla-sources and gentoo-sources).
> Kernel devs themselves deem it dangerous and they don't maintain that
> branch anymore.

Thanks, Roman. This is very useful lore. As I noted, I've moved on to
2.6.36-gentoo-r5.

> > In almost every case, I've found that people who lecture me online about
> > my system admin practices don't really have a handle on the issue about
> > which I'm writing. Please prove me wrong :-)
>
> I suppose one can say I've done just that, having written what I've
> written. At least I hope did so in a sensitive way. There's no need to
> defend your admin skills in case you happen to feel offended by
> something above. Why is there no need? Because failing in an honest
> effort is not a reason for disregard for a human being. So there's
> actually no harm for you from that.

No problem, sir. I've already moved on.

Tonight or tomorrow evening I'll add the necessary minimal mods to the
stock build of the Gentoo kernel noted above, and take another shot at
this problem. _If_ I continue to have this problem then I'll post my
results to this list in a somewhat more ordered fashion. Rather than
posting my entire kernel .config, emerge --info and /etc/fstab to this
list, which I consider questionable netiquette, I'll put it on my
personal file space on one of my servers and post the URL. We can take
it from there.

Thanks for your help. Unless you have specific suggestions for me to
try out, you might want to stand by until I've had a chance to take a
shot at the problem with the newer kernel.

lh

--
Lindsay Haisley | SUPPORT NETWORK NEUTRALITY
FMP Computer Services | --------------------------
512-259-1190 | Boycott Yahoo, RoadRunner, AOL
http://www.fmp.com | and Verison

On 11:36 Sun 20 Mar , Lindsay Haisley wrote:
> On Sun, 2011-03-20 at 08:24 +0000, Jean-Marc Beaune wrote:
> > This is due to ATA/ATAPI (DEPRECATED) being disabled in newer kernels,
> > replaced by Serial ATA and Parallel ATA drivers.
> >
> > Make sure you enabled this support properly.
> >
> > In my case that happened to me as well, on a remote computer, which
> > was my mother's box...
> >
> > Anyway, in fstab /dev/sdXX shoud work, at least I made this change on
> > a couple of machines and that went fine.
>
> Jean-Marc, thanks. This gives me a bit of insight.
>
> I've been compiling kernels for this box for some time, carrying over
> the .config file between kernel versions and updating them. Last night
> I built IDE functionality as a module (it was previously compiled into
> the kernel, as per my carried-over .config files) thinking that I would
> simply not load it at run-time. As I noted in my post, while the the
> kernel recognized "root=/dev/sda4" as a kernel param, the boot process
> crashed with a note that "/dev/sda4" wasn't recognized. It's entirely
> possible that this module got auto-loaded, or that there's some other
> anomaly in my kernel config that's throwing things off.

I also suspect What Jean-Marc said is the problem. I'd recommend
completely disabling everything in the old ATA section to ensure it
doesn't attempt to control any devices, while building the PATA driver
into the kernel and using root=/dev/sdXN in the grub parameters.

The module approach should also work, but I always get a little
suspicious that it might build something else into the kernel
unnecessarily that causes problems.

> My next step is to completely rebuild the kernel, using the config built
> into the distributed kernel source, making only the necessary mods for
> the box's hardware needs. I'll find a time window during the next few
> days to work on this.

It might be a worthwhile step to boot from a LiveCD and run `lspci -k`
to identify the kernel modules. If the pciutils version on the CD is too
old, `pcimodules` might work instead.

--
Thanks,
Donnie

Donnie Berkholz
Desktop project lead
Gentoo Linux
Blog: http://dberkholz.com

On Sun, 2011-03-20 at 21:13 -0500, Donnie Berkholz wrote:
> I also suspect What Jean-Marc said is the problem. I'd recommend
> completely disabling everything in the old ATA section to ensure it
> doesn't attempt to control any devices, while building the PATA driver
> into the kernel and using root=/dev/sdXN in the grub parameters.

If I use the stock configuration from the 2.6.36-gentoo-r5 kernel, won't
this have the correct basic kernel facilities built in, at least as far
as the deprecated IDE capabilities are concerned and the libata
replacement? I assume the Gentoo devs modify kernels so that the
default config settings are more appropriate than those which come with
the vanilla kernel from the kernel devs, yes?

Putting "root=/dev/sda4" on the kernel cmd line in grub actually worked,
and got me a bit further in the boot process. The kernel obviously
understood it. However later in the boot process, I got "Checking the
root filesystem", following by an error message that the root filesystem
spec of /dev/sda4 wasn't understood. This is a complaint about the root
fs spec is in /etc/fstab, since I had been using a UUID spec there, and
got an error at the same point in the boot-up about the UUID instead.

> The module approach should also work, but I always get a little
> suspicious that it might build something else into the kernel
> unnecessarily that causes problems.

I don't know. According to the the ebuild notes with udev, the IDE
facility in the kernel is completely depricated and needs to be turned
off entirely to prevent unexpected results. If I build IDE as a module,
my concern is that the module will get auto-loaded and I'll be back in
the same boat. So I'll use a more recent kernel and turn IDE off
altogether and we'll see what happens.

>
> > My next step is to completely rebuild the kernel, using the config built
> > into the distributed kernel source, making only the necessary mods for
> > the box's hardware needs. I'll find a time window during the next few
> > days to work on this.
>
> It might be a worthwhile step to boot from a LiveCD and run `lspci -k`
> to identify the kernel modules.

lsmod will probably give the same useful information.

> If the pciutils version on the CD is too
> old, `pcimodules` might work instead.

Nope. The my rescue CD is up-to-date.

Thanks!

--
Lindsay Haisley | "Everything works if you let it"
FMP Computer Services | (The Roadie)
512-259-1190 |
http://www.fmp.com |

Lindsay Haisley wrote:
> << SNIP >>
> lh
>
>
One other thing since this appears to be a PATA/IDE driver issue, make
sure you remove the old IDE part in the kernel. I forgot that on my
system when I switched from the old IDE drivers to PATA.

Also, if you use grub, you may be able to learn if things are laid out
the way you think they are. I had two IDE drives attached to the mobo
and one SATA drive attached to a SATA PCI card. I expected the kernel
to see the drives attached to the mobo first then the drive connected to
the SATA card. It didn't work that way. I used grub to figure out that
it was seeing the drive attached to the card first then the drives
attached to the mobo.

This info may not help but thought it worth mentioning just in case.

Dale

:-) :-)

On Sun, 2011-03-20 at 23:59 +0000, eamjr56@gmail.com wrote:
> your not all that good a sysadmin as you claim to be and you surely
> can't admin a Gentoo box.

As a matter of fact, eamjr56, in addition to my desktop system, I admin
a Linux firewall and two commercial public servers, all running Gentoo
Linux. All of them work well, and have never been hacked or
compromised. I've been doing this for about 7 years, and have been
working professionally with Linux for about 16 years. I would guess
from your attitude, eamjr56, that I've probably _forgotten_ more about
Linux than you know, and I really don't need to prove myself to you, or
anyone else.

'nuff said. Please do me a favor and excuse yourself from any further
postings to this thread.

--
Lindsay Haisley | "Real programmers use butterflies"
FMP Computer Services | - xkcd
512-259-1190 |
http://www.fmp.com |

On Sun, 2011-03-20 at 21:39 -0500, Dale wrote:
> One other thing since this appears to be a PATA/IDE driver issue, make
> sure you remove the old IDE part in the kernel. I forgot that on my
> system when I switched from the old IDE drivers to PATA.

I turned it into a module, but the module may have been auto-loaded. I
didn't check.

> Also, if you use grub, you may be able to learn if things are laid out
> the way you think they are. I had two IDE drives attached to the mobo
> and one SATA drive attached to a SATA PCI card. I expected the kernel
> to see the drives attached to the mobo first then the drive connected to
> the SATA card. It didn't work that way. I used grub to figure out that
> it was seeing the drive attached to the card first then the drives
> attached to the mobo.

I don't think this is the issue. The rescue disk brings up all of the
drives, including some LVM drives on the mapper device, which are built
on top of RAID-1 pairs. Although in a boot w.o. the rescue disk, the
kernel recognizes the root filesystem when I spec it with /dev/sda4 in
grub.conf, this recognitions seems to be lost later in the boot process.

There may be some conflicts. /dev/hda1 is a VMware partition, which
becomes /dev/sda1 in newer kernels. /dev/sda1 is also a SATA partition
which is part of a RAID-1 array. The Linux RAID-1 and LVM stuff seem to
pretty much take care of themselves, as long as the RAID and
device-mapper drivers are available in the kernel or as modules, and
this seems tangential to the problem.

--
Lindsay Haisley | "Everything works if you let it"
FMP Computer Services | (The Roadie)
512-259-1190 |
http://www.fmp.com |

On Mon, 21 Mar 2011, Lindsay Haisley wrote:

> I don't know. According to the the ebuild notes with udev, the IDE
> facility in the kernel is completely depricated and needs to be turned
> off entirely to prevent unexpected results. If I build IDE as a
> module, my concern is that the module will get auto-loaded and I'll be
> back in the same boat. So I'll use a more recent kernel and turn IDE
> off altogether and we'll see what happens.

Yes, turn the whole Pata section off. After that, everything should be
recognizable with "sd" rather than "hd" device names, in both Grub and
/etc/fstab. Also, to save yourself trouble, build the drivers for the
Sata subsystem and your particular controller chipset into the kernel,
and forget about initrd's. The only thing they're good for is distros
that have to run on whatever they're booting up on. The minute you have
to compile your own kernel to suit yourself, you might as well get rid
of the hassle of initrd's while you're at it.

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

[reordered the paragraphs]

> Unless you have specific suggestions for me to
> try out, you might want to stand by until I've had a chance to take a
> shot at the problem with the newer kernel.

I do have a few. I hope you'll make a good use of them to make your
life more productive.

> > And I need to see your conf to discover such potential
> > mistakes. As for `emerge --info`, it may uncover problems relevant in
> > this case too.
>
> "emerge --info" is the the stock Gentoo system profile, and I'll be
> happy to share it, but in this case I'm looking at what's almost a
> "pre-Gentoo" issue, involving the kernel and the boot-up.

This sounds like you're sure that there is nothing interesting to
see in `emerge --info`. Well, let's change it into something more
correct: according to your knowledge there is nothing interesting to
see. But your knowledge isn't perfect (just like anyone's). Keeping
that in mind while consulting with others is the first of my specific
suggestions into the future. It will save your+our time and may get you
the solution faster.

> > Please, cooperate with those whom you'd asked for help. Writing these
> > several paragraphs worth of e-mail text as a reply was a waste of time
> > for you - it clearly hasn't produced any help at all regarding your
> > booting issue.
>
> Taking the desktop system off-line, re-emerging udev, bringing it up
> into its failure mode with a newer kernel and pulling the necessary
> pieces together, then backing out and putting everything back so the
> system is actually fairly usable is a major hassle. I have had _zero_
> time to work on this problem since I posted this morning, but will be
> able to take another run at it this evening, hopefully. Writing is no
> effort for me, and doesn't disable my desktop ;)

The second of my specific suggestions into a more fruitful future is:
read what people ask of you. Sending me what I'd asked for would've
taken about a few dozen seconds (I suppose you have the config for
2.6.29 stored somewhere). It certainly wouldn't entail taking your
desktop offline, reemerging udev, etc. etc. It's just attaching two
text files to a piece of e-mail. So if your current attempt at 2.6.36
(was it?) fails, you know what to do right away.

> > And some of those are relatively serious security holes and it'd take a
> > really special handling of the system to avoid them. And I'm talking
> > about handling that'd probably render an Internet-connected desktop box
> > with a web browser unusable.
>
> This desktop box is on an RFC-1918 masqueraded network. It has zero
> exposure to the Internet, except insofar as the firewall will permit
> traffic from related and established connections, as per the firewall
> NAT rules. The only other person on the LAN is my sweetie, and as far
> as I know I can trust her not to black-hat hack my desktop system :-)
> All my professional work is done via VPNs to my client's systems.

The third suggestion is probably the most important one: being NAT'd
and being behind any iptables configuration (that allows for operations
such as sending mail and browsing the web) doesn't make your PC
invulnerable or anything near that. In other words, active break-in
attempts via open ports is by far not the only option hackers have.

> Rather than
> posting my entire kernel .config, emerge --info and /etc/fstab to this
> list, which I consider questionable netiquette, I'll put it on my
> personal file space on one of my servers and post the URL.

In fact, some people who've appeared on this list over the years would
consider it unacceptably bad netiquette not to include `emerge --info`.
I also recall people who would consider it bad netiquette, but would
still answer your questions (perhaps with some remarks). And I suppose
most others consider it at least a good idea and a potential time-saver
to include it, unless the topic in question is "what laptop should I
buy to run Gentoo". So there goes my last specific suggestion to help
you make a more efficient use of this list: include your `emerge
--info` and relevant config files, if any, in the opening post to a
mailinglist. It's not like you're telling us your card number.

-rz

On Mon, 2011-03-21 at 09:57 +0100, Roman Zilka wrote:
> I do have a few. I hope you'll make a good use of them to make your
> life more productive.

Good heavens, Roman! Please let's back off on the lectures and stick to
the technical stuff. When I have a chance to fully a address the
problem again, if I still have a problem I will take the information you
request and post it, as I said, to a private URL, which I will post to
this list, and NOT send it out to a gazillion subscribers who aren't
interested. This is the way patches, configs, emerge --info, etc is
done on many forums and mailing lists. This is the way it WILL be done
in this case, and I'm sure you can deal with it.

This is NOT an operation of a few dozen seconds. I will post to this
list when I have time to fully focus on the problem. In the meantime, I
don't intend to argue with you or anyone else about what does or does
not constitute proper netiquette. I'm 69 years old, have been
programming in numerous languages and working with Unix since the mid
80s, have been working with Linux since kernel v1.x.x in the 90s, am
past president of the oldest Unix pofessional society in Austin, TX,
co-founder of the oldest Linux Users Group in Austin, have moderated
more mailing lists than I care to remember, run a small but well
respected hosting service here, and am not without knowledge and
resources. I come to this list with this problem not because you, or
anyone else "knows more than I do", but because people may have
technical insights or suggestions that may help me understand what's
going on. Let's keep it to that going forward.

> The second of my specific suggestions into a more fruitful future is:
> read what people ask of you.

Jesus, Roman! BACK OFF!! I'm sorry if I offended you, but your
response is offensive to me. All it does is annoy me and encourage the
script kiddies on the list to take cheap shots at me. I appreciate your
insights, but please let's stick to the technical issues. _IF_ I need
to, I will post the material you request in the manner I've noted
previously, at such time as I have my work on the problem better
organized. Don't waste my time, and I won't waste yours. OK?

Again, I sincerely apologize if I've wasted your time, or anyone else's
on this list, and I'll try to keep my posts to a minimum going forward
until I have more to report. Again, going forward, PLEASE stick to
technical matters and let's let issues of style, netiquette, etc. alone.
Thank you, and 'nuff said about that. And again, please accept my
apology.

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

Roman, et al, since you, and maybe others seem to be incredibly hot to
trot on my desktop booting issue, the files you requested are at

<http://www.fmp.com/~fmouse/vishnu/>

/etc/fstab (vishnu_fstab.txt) is configured as per the _working_ kernel
on the box, which is 2.6.21-gentoo-r1. When booting from a more recent
kernel, the 1st three lines will be changed to spec /dev/sdXn instead
of /dev/hdXn.

The kernel config (vishnu_kernel-2.6.29-gentoo-r5_config.txt) is suspect
at this point, as per Roman's information re. 2.6.29 being a thoroughly
discredited kernel version. This configuration will _not_ be used going
forward into a more recent kernel.

vishnu_emerge_info.txt is "emerge --info" from the box. I'm not sure
how this will give you any insight into the booting problem on the box,
but since you seem to have your knickers in a knot about my _not_
posting it, here it is :-)

Kernels on the box are built manually, using "make bzImage" and friends,
not using genkernel.

When I have some time to take the box down, upgrade the kernel and take
another shot at this problem, I'll update.

--
Lindsay Haisley | "Real programmers use butterflies"
FMP Computer Services |
512-259-1190 | - xkcd
http://www.fmp.com |

Jesus, take your meds already. Roman has only been trying to help you throughout this long sorry episode. This is NOT about your past Unix yada yada, but how well you follow kernel devel, won't look on the Gentoo forums for answers and generally take help. It is not make bzimage for one, it is make, make modules_install, make install. Boot with a Live CD and chroot into yer install, remove ALL options for IDE period. Check SATA. Build, change all HDxxx to SDxx run your bootloader and TADA fixed
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Lindsay Haisley <fmouse-gentoo@fmp.com>
Date: Mon, 21 Mar 2011 11:18:07
To: <gentoo-desktop@lists.gentoo.org>
Reply-to: gentoo-desktop@lists.gentoo.org
Subject: Re: [gentoo-desktop] System problems

On Mon, 2011-03-21 at 09:57 +0100, Roman Zilka wrote:
> I do have a few. I hope you'll make a good use of them to make your
> life more productive.

Good heavens, Roman! Please let's back off on the lectures and stick to
the technical stuff. When I have a chance to fully a address the
problem again, if I still have a problem I will take the information you
request and post it, as I said, to a private URL, which I will post to
this list, and NOT send it out to a gazillion subscribers who aren't
interested. This is the way patches, configs, emerge --info, etc is
done on many forums and mailing lists. This is the way it WILL be done
in this case, and I'm sure you can deal with it.

This is NOT an operation of a few dozen seconds. I will post to this
list when I have time to fully focus on the problem. In the meantime, I
don't intend to argue with you or anyone else about what does or does
not constitute proper netiquette. I'm 69 years old, have been
programming in numerous languages and working with Unix since the mid
80s, have been working with Linux since kernel v1.x.x in the 90s, am
past president of the oldest Unix pofessional society in Austin, TX,
co-founder of the oldest Linux Users Group in Austin, have moderated
more mailing lists than I care to remember, run a small but well
respected hosting service here, and am not without knowledge and
resources. I come to this list with this problem not because you, or
anyone else "knows more than I do", but because people may have
technical insights or suggestions that may help me understand what's
going on. Let's keep it to that going forward.

> The second of my specific suggestions into a more fruitful future is:
> read what people ask of you.

Jesus, Roman! BACK OFF!! I'm sorry if I offended you, but your
response is offensive to me. All it does is annoy me and encourage the
script kiddies on the list to take cheap shots at me. I appreciate your
insights, but please let's stick to the technical issues. _IF_ I need
to, I will post the material you request in the manner I've noted
previously, at such time as I have my work on the problem better
organized. Don't waste my time, and I won't waste yours. OK?

Again, I sincerely apologize if I've wasted your time, or anyone else's
on this list, and I'll try to keep my posts to a minimum going forward
until I have more to report. Again, going forward, PLEASE stick to
technical matters and let's let issues of style, netiquette, etc. alone.
Thank you, and 'nuff said about that. And again, please accept my
apology.

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