| 1 |
> > Also, you should avoid using oldconfig except for really minor kernel |
| 2 |
> > upgrades. I know this is mentioned in documentation elsewhere, but |
| 3 |
> > just a useful reminder. |
| 4 |
> > |
| 5 |
> > ~daid |
| 6 |
> |
| 7 |
> This has been discussed on this list before. Running make oldconfig |
| 8 |
> works fine. I, and a lot of others, have said this many times. I |
| 9 |
> configed one kernel about 5 years ago and have used oldconfig ever |
| 10 |
> since. It is faster and less prone to problems than starting from scratch. |
| 11 |
> |
| 12 |
> If you are going from 2.4 to 2.6, then you should start fresh. I |
| 13 |
> recently went from 2.6.23 to a 2.6.28 with no problem, other than trying |
| 14 |
> to figure out that new group stuff. |
| 15 |
> |
| 16 |
> Dale |
| 17 |
> |
| 18 |
> |
| 19 |
Huh. I was going from 2.6.23 to 2.6.26 about 2 weeks ago and using |
| 20 |
oldconfig was giving me some major trouble as I recall. Not sure |
| 21 |
specifically now, but I know CONFIG_HPET_TIMER had to be turned off later |
| 22 |
during manual configuration, or my machine was hanging after some ACPI |
| 23 |
scripts. This behavior is replicated elsewhere for similar hardware, though |
| 24 |
the author claimed it was fixed after 2.6.25 which I found to clearly not be |
| 25 |
the case. I had also not manually configured my own kernel either, so I |
| 26 |
thought it's worth the experience. |
| 27 |
|
| 28 |
I could save my current configuration for 2.6.26 and try oldconfig again |
| 29 |
from 2.6.23.9 to make another 2.6.26 kernel and see what the problem was. |
| 30 |
|
| 31 |
~daid |
Archives