1 |
> /etc/fstab has been edited several times, as I noted in my post. The |
2 |
> kernel, udev and /etc/fstab have been now been reverted, as I also noted, so |
3 |
> I could get the desktop working. Considering that, posting any of the |
4 |
> information you've asked for would probably be useless. |
5 |
|
6 |
OK, so be it, fstab is not that important. |
7 |
|
8 |
> Roman, if you don't have any useful insights based on the information I |
9 |
> already posted, then please don't post on thread and leave it to others |
10 |
> who may. |
11 |
|
12 |
I may have useful insights that are different from the insights posted |
13 |
previously by other people. But I need your `emerge --info` and kernel |
14 |
conf for that first. To give you a hint of explanation: I need the |
15 |
kernel conf to look for whatever may be wrong in there. There's no |
16 |
point in sending you a working conf for my (i.e., different) machine - |
17 |
there's plenty of those lying around the net, as we both know. I assume |
18 |
you have either already tried one of those or simply don't want to use |
19 |
one for some reason. Thus, it's possible that you keep making a |
20 |
recurring mistake while modifying default / borrowed / your own old |
21 |
configs. And I need to see your conf to discover such potential |
22 |
mistakes. As for `emerge --info`, it may uncover problems relevant in |
23 |
this case too. |
24 |
|
25 |
Please, cooperate with those whom you'd asked for help. Writing these |
26 |
several paragraphs worth of e-mail text as a reply was a waste of time |
27 |
for you - it clearly hasn't produced any help at all regarding your |
28 |
booting issue. On the other hand, sending me what I'd asked for right |
29 |
away would not only eat up much less of your time, it might have |
30 |
yielded a solution by now. I suppose you're asking for help because you |
31 |
understand that others may be more knowledgeable than yourself. |
32 |
|
33 |
> > Also, by upgrading to a little less ancient versions than 2.6.29 |
34 |
> > you won't have the same situation like now boomerang back at you in the |
35 |
> > near future. |
36 |
> |
37 |
> Can you cite a source or sources for this assertion? |
38 |
|
39 |
The source is the very reality of change of things in the world over |
40 |
time. Software evolves and because hardly anything in nature has |
41 |
infinite duration, it is only a matter of time before compatibility of |
42 |
udev (or something else) with the 2.6.29 ends. In fact, this is true |
43 |
for any two pieces of software that coexist, not just the |
44 |
kernel+something, of course. |
45 |
|
46 |
> Is there a known |
47 |
> problem with kernel 2.6.29, or the portage tree which spec'd that |
48 |
> kernel? |
49 |
|
50 |
There are so many known problems with that kernel that it'd take me a |
51 |
lifetime to remember and copy them all. See: |
52 |
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.3?* |
53 |
|
54 |
And some of those are relatively serious security holes and it'd take a |
55 |
really special handling of the system to avoid them. And I'm talking |
56 |
about handling that'd probably render an Internet-connected desktop box |
57 |
with a web browser unusable. I'm not gonna google those specific ones |
58 |
for you, we don't need that to get ahead; every active admin will |
59 |
remember them. |
60 |
|
61 |
And yes, Gentoo devs deem 2.6.29 dangerous too - that's why it isn't in |
62 |
the current Portage tree at all (vanilla-sources and gentoo-sources). |
63 |
Kernel devs themselves deem it dangerous and they don't maintain that |
64 |
branch anymore. Of what's maintained (in terms of security patches), |
65 |
2.6.27 and 2.6.32 are nearest to 2.6.29. And I wouldn't expect at least |
66 |
one of them to linger around for a very long time. |
67 |
|
68 |
> In almost every case, I've found that people who lecture me online about |
69 |
> my system admin practices don't really have a handle on the issue about |
70 |
> which I'm writing. Please prove me wrong :-) |
71 |
|
72 |
I suppose one can say I've done just that, having written what I've |
73 |
written. At least I hope did so in a sensitive way. There's no need to |
74 |
defend your admin skills in case you happen to feel offended by |
75 |
something above. Why is there no need? Because failing in an honest |
76 |
effort is not a reason for disregard for a human being. So there's |
77 |
actually no harm for you from that. |
78 |
|
79 |
Well, in fact, it is a reason for disregard for a few people, but let's |
80 |
not have our lives spoiled by those.:) |
81 |
|
82 |
-rz |