On Jan 1, 2015, at 3:49 PM, Don Vogt dnvot@yahoo.com wrote:
when I select the second kernel it boots OK. Now I would like to remove the bad kernel.
The only thing that makes this tricky is that you can’t just say “rpm -e kernel” because there is more than one “kernel” package installed. You need to know the exact package name.
It sounds like you know the full package name, but if you didn’t, a command like this will find it for you:
$ rpm -qf /boot/vmlinuz-3.10.0-123.4.2.el7.x86_64
vmlinuz-* is the kernel image on most Linuxes, and they usually live in /boot.
The command to remove that particular kernel on an EL7 box is:
$ sudo rpm -e kernel-3.10.0-123.4.2.el7.x86_64
I’m assuming you’re using EL7 and you told it you wanted your user to be a trusted admin during install. Otherwise, you might need to su up to root to do this. Alas, sudo is not universal:
http://unix.stackexchange.com/questions/48522/how-universal-is-sudo
I have never noticed a "centos-plus" in a kernel name before. Does the centos-plus repo deal out kernels?
Clearly, the answer is “yes”.
This happened because you enabled the centosplus repo in /etc/yum.repos.d, then said “yum update”. Whenever the centosplus kernel is newer, it gets installed as the default instead of the stock OS kernel.
This is why I never leave nonstandard repos permanently enabled. I always enable them on a one-off basis:
$ sudo yum --enablerepo=centosplus some-weird-package-i-need
That enables the centosplus repo for just that one command.
I would appreciate any advice (except "go back to windows”)
You asked for it: Get and read some good books on Linux.
I would recommend both some books that focus generally on Unix type systems (e.g. Unix System Administration Handbook) as well as some focused specifically at the version of Linux you are using right now.
One gets you practical details you can use today, while the other gets you philosophy that will inform your reaction to the changes that will come throughout the rest of your career.
You cannot properly learn Linux just by Googling and asking questions on forums, mailing lists, and Unix.SE. Books are still the densest form of reliable technical information available.