Gentoo update tips when updating packages with blocks and masked files

It’s not so rear to have

blocks or masked files

when using Gentoo emerge system, but it is not complex and in most cases it is easy to resolve

To summarize it up at the beginning and then we are going to show you other articles using these advises here where you’ll see what are the steps we took to resolve the conflicts and masked packages:

  • Use verbose,verbose-conflicts and backtrack with emerge
  • Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
  • Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
  • Do not update everything with one line, you could update only the base libraries like QT, which are very important for the Linux GUI in general
  • Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.
  • use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
  • Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
  • In rear cases you can use “–nodeps” when updating or installing a new package (we do not need and show this one here!)
  • Do NOT rebuild the entire system with “emerge -v world” every time when you rebuild glibc, gcc, it is not mandatory to do it to have a healthy system.
  • Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
  • use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
    emerge -v $(qlist -IC|grep <NAME>)

    and for update just add “u” to “-v”:

    emerge -vu $(qlist -IC|grep <NAME>)

Keep on reading!

How to proper enable the selinux in a CentOS7 installed server

These days many dedicated servers are offered with automation installation of operating systems and it have never been so easy and fast to pay a server and to get it up in minutes! Yes, we are talking for dedicated machines not virtual servers or cloud ones, but many cloud ones are in the same situation, when the host uses full virtualization.
It is fast, you can choose from many different linux distros and the installation is unattended and happens immediately, but in most cases the selinux is disabled, because is more easy for the support, for the user, for the admin, and for the offered preinstalled software…If you do not have some strange software in most cases it is advisable to enable the selinux, because it is of great security enhancement for your server and for the software in general. It is very simple to enable selinux, but there is an additional step, which if you omit, the server will probably get unusable (probably you won’t be able even to ssh it or login). These steps are tested under CentOS7, but probably works in all other distros, which support selinux!
So here are the steps:

STEP 1) Enable selinux in configuration

Edit the configuration file in



STEP 2) relabel the file system

When using the selinux, there are labels (extended attributes of the file system), which are additional layer of security. Every system comes with prebuild rules instructing what label is set in which file or directory, so when you enable the selinux you must relabel the entire file system (or at least the root partition, to be able to boot normally). This is done with just a line of code below:

touch /.autorelabel

STEP 3) reboot

To take effect the changes made above the server must be rebooted.


The init process will find the file from step 2 “/.autorelabel” and will initiate a proper relabel according the current selinux rules file, then the server will be rebooted automatically again, the relabel could take time and it depends on the number of files you have in your server, just keep patient.
After the second reboot (which is automatically after the relabeling)

4) Recommendations

USE SELINUX, do not disable it! In most cases it is really simple to configure it in minutes for the need of your special software and for the generic one bet it there are rules offered in the distro’s packet system.

4) Post install check

You can check if the selinux is enabled with

[root@srv ~]# getenforce 
[root@srv ~]#