This is why Linux will never gain any popularity among regular users and should never be advocated to them in any form.
After a big update and a new kernel on my CentOS 7 installation, that particular kernel, the latest and greatest, with all the goodies promised- is unbootable. Booting process drops down to emergency shell, where I am stuck in a loop of checking log files, trying to mount /sysroot, listing /dev, xfs_repair-ing, all of that to no avail. Emergency shell insists that there is no entry for /sysroot in /etc/fstab.
Previous kernels boot normally. Pitty those that depend exclusively on Linux for their personal computing. Feeble and terribly untested piece of work of garage tinkerers.
Newbies and those that plan to wander into the jungle that is FOSS, I hope you heed this warning.

That may be your experience but it's not mine, I've recently updated dozens of CentOS7 server to the latest 7.2 release without problems. What you haven't mentioned is whether this is a server or desktop CentOS and whether you have any extra repositories in use (they sometimes cause problems)but I guess you also did a backup before doing such a major upgrade?

It is a desktop CentOS, I have adobe-linux repo, epel, epel-testing along with the chrome and nux-dextop repos in addition to Centos-this and Centos-that repos. Hey, such a doll you are with the attempt on putting the fault on the user but no- I don't rely completely on technology that will fail catastrophically just because. It was working fine, until someone in the Torvald's Shrine decided to destroy what was working. I am almost sure the update doesn't bring any new functionality.
What is the size of boot partitions on your servers?

The primary reason the last kernel is not deleted. CentOS uses the Red Hat Enterprise Linux kernel which is custom built and goes through a set of quality assurance tests. Neither Redhat nor the kernel developers can test for all possibilities of hardware and software configurations but it is unfortunate that the kernel upgrade failed for you. You can submit a bug report to CentOS.

i am betting that your problem is related to having this enabled -- it is DISABLED BY DEFAULT!!!!
" epel-testing "

that or
you are using the proprietary Nvidia.run or AMD.bin graphics driver
and did not read the instructions and having to reinstall that after EVERY kernel update

by the way
i have had ZERO issues with CentOS or Scientific Linux in the last ten years
It is one of the BEST tested and MOST stable OS there is

it is the Operating system i use fo EMERGENCY back ups and EMERGENCY booting and issues
it is the OS that i KNOW WITH 100% CERTAINTY that it will ALWAYS work

http://www.linuxquestions.org/questi...7/#post5469017

http://www.linuxquestions.org/questi...ml#post5405771

So you can see where this is going.

1 members found this post helpful.

It is users' fault! Of course! Darn users!
I am betting, safer than your bet, that there are more computers with those drivers than there are Linux users relying completely on Linux. Around the world.
And here's something more for you to ponder on: those (according to you) proprietary drivers that are needing to be re-installed after every update, previous kernels have no problem using. Provided that I have them on my computer.
Following your logic, I'd have to expect a catastrophic failure every time I boot into Linux. Who lives like that? Who wants to own and work on a system like that?

Yes, and others - just look through posting history.

You would think that anyone so utterly, repeatedly dissatisfied with their GNU/Linux experience would just quit using it and move on.

On the other hand, trolls and shills continue to pretend only for their own perverse satisfaction. What better way to spend an evening than raining down someone else's back.

Then stop upgrading your kernel or go back to Windows.

v4r3l0v : no one is blaming the users, just YOU!

You have a system with one of the most conservative, stable operating systems in the world installed, with repos to enable load of unstable and experimental software. Rather than helping to define and discover the real issue, you elect to complain and blame the base distribution maintainers. Suck it up and take some responsibility here. No one else appears to have this problem, and were it a problem with CentOS it would be EVERYWHERE.

We can help. We need enough information to make a stab at it to even start.
The question is: did you come for help or only to rant?

We will not help you rant, you do that well enough alone.

Of course! How dare I question your dogma, such a heretic. The most conservative and stable OS that won't boot. Yet you hold it in such a high esteem. That tells more about you then about anyone else.
If you really want to help, you'd do two things:
- help me by telling me the size of /boot partition of your machine(s) that successfully upgraded.
- read users' horror stories with Linux from around this forum, count how many were "solved" by user erasing his/her original installation and installing something else and then come back and tell me how great Linux is.
I am almost sure no. 2 won't happen. Ever.

It's clergy like you that keeps me coming back. Purge the heretic. I wonder where you learned this.

Why don't you provide some information instead whining about it.

You were told we could help. If you have "epel-testing" enabled, then backout the change you asked for. This repository is only for TESTING, not production.

And griping about a kernel without identification of which kernel release is of no help. By the time the kernel reaches CentOS, it will be nearly a year old - and very well tested. It is very unlikely to be a kernel problem unless some parameters got goobered; even then, it can be recovered in single user mode.

Perhaps... but they will only be Windows users.
You don't seem to understand drivers very well. The reason they need to be rebuilt is that the kernel developers will update kernel interfaces. They cannot update the interfaces used by proprietary drivers as they are not available. This is why there exists such things as NDISwrapper exist. This driver wrapper must be rebuilt for each kernel. Its only function is to translate the current kernel interface into something a Windows driver can use. The Windows driver itself doesn't get recompiled - only the NDISwrapper.

Unfortunately, the changes aren't always compatible with the driver. When that happens you have to wait for the changes to the wrapper for updates to the translation.

Now within a minor kernel update, the driver being used MIGHT be compatible - but it isn't guaranteed.

Oh such maestral description, I wonder then what's the kernel developers' practice- knowing fully that there are A LOT of machines out there with a potential to break when their interfaces to proprietary drivers get "updated". And I really doubt developers are unaware of the massive number of machines with that particular point of failure. So would it make sense to have that into account? Not in the Linux world, it seems.