FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Desktop

 
 
LinkBack Thread Tools
 
Old 03-20-2011, 10:10 PM
Roman Zilka
 
Default System problems

> /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
 
Old 03-20-2011, 10:19 PM
Roman Zilka
 
Default System problems

> 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
 
Old 03-20-2011, 10:59 PM
 
Default System problems

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
 
Old 03-20-2011, 11:50 PM
Lindsay Haisley
 
Default System problems

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 |
 
Old 03-21-2011, 12:57 AM
Lindsay Haisley
 
Default System problems

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
 
Old 03-21-2011, 01:13 AM
Donnie Berkholz
 
Default System problems

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
 
Old 03-21-2011, 01:38 AM
Lindsay Haisley
 
Default System problems

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 |
 
Old 03-21-2011, 01:39 AM
Dale
 
Default System problems

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

:-) :-)
 
Old 03-21-2011, 01:46 AM
Lindsay Haisley
 
Default System problems

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 |
 
Old 03-21-2011, 02:36 AM
Lindsay Haisley
 
Default System problems

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 |
 

Thread Tools




All times are GMT. The time now is 12:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org