Tag Info

New answers tagged


It's a bug: Apr 12 05:33:51 vps kernel: BUG: Bad page map in process crond pte:00000f00 pmd:436a14058 You're running RHEL: Apr 12 05:33:51 vps kernel: Pid: 22373, comm: crond Not tainted 2.6.32-358.18.1.el6.x86_64 #1 First, open a ticket with RH. If that doesn't bear fruit, update the kernel and pray it doesn't happen again. There's no "magic fix" ...


In grub.conf you have a line that looks like default=0. That's the order number of the kernel in the grub titles list, first one is 0.


This is most likely due to your new kernel not having a driver for your file system. Details on your disk/controller along with your .config would help us determine whether this is the case. It could also be initramfs thinking that devtmpfs is available when it is not. If this is the case, add CONFIG_DEVTMPFS=y to your .config


Please check if your grub configuration has been updated. update-grub2 Then check /boot/grub/grub.cfg.


Use yum distro-sync instead of yum update to fix package version mismatches in this scenario. This allows for packages to be downgraded if necessary to match the versions in the repositories.


No, it does not. If it's not running, it's merely a file in the file system. If an attacker manages to restart your system with this kernel, he has already full control over the system anyway.


When you install both 32 bit (.i686) and 64 bit (x86_64) versions of the same library, they must be of the same version. If you examine the Error messages that you posted above, you'll see that the versions are not the same (the "!=" part means "does not equal"). Use following commands to fix the error, Use package-cleanup to remove duplicates. ...


Yes, this is a valid way to check that the socket is non-blocking. The value for a non-blocking socket is 04000, non-blocking sockets in /proc/<pid>/fdinfo are represented in octal. You can validate this behaviour with python. Python 2.7.5 (default, Feb 19 2014, 13:47:28) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type "help", "copyright", ...


OpenVZ has the kernel that is shared between host and all containers, thus settings that might affect other containers and host are prohibited from modifications from inside a container. You can try to change these denied settings on host, they might be applied to all containers (OpenVZ kernel controls what is and what's not applied) This has been also ...

Top 50 recent answers are included