1 |
Peter Humphrey wrote: |
2 |
> On Sunday 14 October 2012 15:46:43 Dale wrote: |
3 |
>> Francisco Ares wrote: |
4 |
>>> As my old kernel is from the 2.6 series and the new is from the |
5 |
>>> 3.4, I decided to do a "menuconfig" from scratch. I do use "lspci" |
6 |
>>> and also I always build the kernel allowing "/proc/config.gz", so |
7 |
>>> it is easy to get exactly what is working, although I keep my own |
8 |
>>> bacup copies of ".config", for future references. When I am |
9 |
>>> building a kernel, I use to open the latest ".config" in a |
10 |
>>> separate console, for reference. That has kept me of forgetting |
11 |
>>> plenty of details. |
12 |
>>> |
13 |
>> I can understand why. There would have been a huge number of new |
14 |
>> options to check on. Doing it from scratch with menuconfig could |
15 |
>> have been just as fast or maybe even faster. May have been worth |
16 |
>> trying but may have ended up with more issues. |
17 |
> I found long ago that menuconfig flags new options with [NEW] to the right |
18 |
> of the option name, so it's easy to find out what's changed since you |
19 |
> last ran a config operation. That can easily reduce a several-hours config |
20 |
> job to no more than half an hour. Still quite a task, but not in the |
21 |
> same league as configuring from scratch. |
22 |
> |
23 |
|
24 |
|
25 |
It does but you have to go through each menu to see what is new and what |
26 |
is not and that's a lot of menus and submenus etc, etc. It still |
27 |
increases the odds of missing something. Heck, even tho I use lspci -k |
28 |
to make sure I have everything included for hardware, there is always |
29 |
some piece of software that wants something added. Those are really |
30 |
hard to keep track of, unless you make a lot of notes. That's where |
31 |
oldconfig comes in since it only adjusts the new stuff and leaves the |
32 |
old stuff like it was. |
33 |
|
34 |
Using oldconfig is the fastest and easiest and as a general rule gives |
35 |
you a good kernel. But when you are upgrading from that many version |
36 |
ago, you could end up with something flakey or other odd things. |
37 |
|
38 |
I think the OP likely did the best thing by just starting over. Also, |
39 |
maybe now he knows to upgrade a little more often. lol We often learn |
40 |
this the hard way. Just like when people don't sync and upgrade the OS |
41 |
for a year or two. Depending on changes, reinstalling may be easier |
42 |
depending on what issues have cropped up in that time and how fast a rig |
43 |
can compile things. Again, it just depends on the situation and even |
44 |
then can be a toss up as to which is the right way to go. Those of us |
45 |
that have been around here a long time have seen people try to update a |
46 |
badly out of date OS just to run into so many issues that they end up |
47 |
reinstalling again anyway. The time spent trying to fix it can be |
48 |
longer than just starting over sometimes. Not to mention having hair |
49 |
left. ;-) |
50 |
|
51 |
Me, I might would have tried it but not going to argue over it. The OP |
52 |
is up and running and that is the important thing. It was only a few |
53 |
electrons that were bent out of shape. lol |
54 |
|
55 |
Dale |
56 |
|
57 |
:-) :-) |
58 |
|
59 |
-- |
60 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |