I think it’s fair to set an example after making such bold statements (check about page), so here it is.

Once, there was a case where a bug related to recent CentOS 7 update caused server downtime due to issues with SELinux policies. In addition to that, package dependencies were completely messed up, which made the fixing of initial problem impossible. The correct solution to this would be removing faulty packages from rpm database, similar to this:

# rpm -e --justdb pkgname

Apparently, I had a better idea… I told the customer to run yum instead. And the package was…

# yum remove grub2-tools-extra

Seems innocent enough, right? But let’s forget about it for a second, we have dependencies to fix, removing must have eliminated the collision, so let’s check if system update installation goes well… It does! Okay then, let’s restore the package that was removed, surely, grub packages are not the least required…

Little did I know that yum’s logic would look similar to this:

“Since you don’t need grub2-tools-extra, you must want to get rid of grub2 as well!
Come to think of it, you won’t have grub2, so why would you need grub2-efi-modules? Let’s remove that too!”

… and this:

“Hey, so you want me to install this grub2-tools-extra back? Well, if there’s nothing else, here you go.”

While I was oblivious to this, as there was no direct access to the console output, it doesn’t make the whole thing less stupid. Wanna know why?

I gave greenlight for a reboot.

Want to spend next 4.5 hours restoring the machine, connected through TeamViewer which jumps to Hyper-V via RDP? Well, here’s your recipe.

Type: Ticket handling
Score: Bad
Reason: Lack of attention to actions of incompetent peer