| 1 |
William Kenworthy wrote: |
| 2 |
> |
| 3 |
> and don't forget to run "uname -a" to get your currently running |
| 4 |
> kernel version and make sure you don't delete that! |
| 5 |
> |
| 6 |
> "IF" "uname -a" isn't the latest version you have in /boot, some more |
| 7 |
> investigation as to why will be needed. |
| 8 |
> |
| 9 |
> BillK |
| 10 |
> |
| 11 |
> |
| 12 |
|
| 13 |
|
| 14 |
Just to add another method. I have uprecords installed here. It lists |
| 15 |
the kernels and their uptime. I keep the last two with reasonably high |
| 16 |
uptimes with fairly recent version and the most recent kernel. I don't |
| 17 |
upgrade automatically so I control what and when I update. Of course, I |
| 18 |
also have long uptimes as well. My thinking on this. I want kernels |
| 19 |
that are known to be stable that I can use as a backup boot option but I |
| 20 |
also want newer kernels that have fixes etc in them. By keeping a |
| 21 |
couple with long uptimes, I get stable kernels. By also picking a |
| 22 |
recent kernel version, I get a kernel that I can boot into to see if it |
| 23 |
is stable. Over time, the versions get higher on both parts. When I do |
| 24 |
my checks, I look for kernels with at least 30 days or more of uptime. |
| 25 |
Generally, if a kernel can run that length of time, it is pretty |
| 26 |
stable. That said, I have some with many months of uptime. |
| 27 |
|
| 28 |
When I upgrade to a new kernel, I run for a month or so and then |
| 29 |
manually clean out /boot, that would include kernel, init thingy, |
| 30 |
System.map and config files. |
| 31 |
|
| 32 |
Seeing this reminds me it might be a good time to look into updating, |
| 33 |
even tho I might not reboot for a while yet. |
| 34 |
|
| 35 |
Just a thought. |
| 36 |
|
| 37 |
Dale |
| 38 |
|
| 39 |
:-) :-) |
Archives