Est-il acceptable d'éliminer kernel-debug * sur un système de production s'il empêche les mises à niveau? Modèle KVM: / boot n'a pas assez d'espace

Il existe donc des templates VPS CentOS 6.x hérités sur un très bon hôte qui sont "bloqués" avec une partition de 100 Mb / boot. Malheureusement, il y a 4 ans, l'un de nos servers appartient à cette catégorie. À défaut de changer de zone pour get un nouveau package / model avec plus d'espace, il n'y a aucun moyen d'augmenter la taille de / boot. Les zones de commutation seraient tout à fait nécessaires puisqu'il y aurait de nouveaux IP et d'autres schémas à refaire, donc nous recherchons des alternatives.

Nous utilisons CloudLinux sur ce server, donc peut-être que les kernelx sont un peu plus gros que la normale. Quoi qu'il en soit, nous sums obligés de recadrer les kernelx actifs en 1, ce qui me dérange, mais c'est tout ce qui peut entrer dans / démarrer. Le problème est qu'il y a un manque d'espace disponible pour installer de nouvelles versions du kernel.

Les packages Kernel-debug * semblent être plus grands que le kernel standard. Est-il sécuritaire de les enlever? Les kernelx de debugging sont-ils utiles pour la production si une ancienne version d'un kernel standard [potentiellement] est disponible pour démarrer?

Il s'agit d'un VPS de production multi-locataire (KVM) avec LAMP. Nous ne faisons pas beaucoup de CLI côté server sur ce site, il s'agit principalement d'ecom + webapps. Il y a des connaissances sur Kernelcare si cela pourrait fournir une sorte de solution de contournement.

One Solution collect form web for “Est-il acceptable d'éliminer kernel-debug * sur un système de production s'il empêche les mises à niveau? Modèle KVM: / boot n'a pas assez d'espace”

Avec kernel-debug *, vous entendz à la fois kernel-debug ainsi que kernel-debuginfo car il existe une différence entre ces deux packages

Kernel-debuginfo: Provides a executable image of the kernel with all the debug symbols Kernel-debug: Enables some debugging code but not have same debug symbols on it ### Excerpt from RedHat Doc ### The kernel-debug enables the following options on the kernel that are disabled on the default kernel: CONFIG_DEBUG_SLAB Makes kernel do limited verification on memory allocation as well as poisoning memory on free to catch use of freed memory. (performance impact mainly on kmalloc / mfree calls). CONFIG_DEBUG_MUTEXES Allows mutexes semantics violations to be detected and reported. CONFIG_DEBUG_RT_MUTEXES Allows rt mutex semantics violations and rt mutex related deadlocks (lockups) to be detected and reported automatically. CONFIG_DEBUG_RWSEMS Allows read-write semaphore semantics violations to be detected and reported. CONFIG_DEBUG_LOCK_ALLOC This feature will check whether any held lock (spinlock, rwlock, mutex or rwsem) is incorrectly freed by the kernel, via any of the memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), vfree(), etc), whether a live lock is incorrectly reinitialized via spin_lock_init(),mutex_init(),etc, or whether there is any lock held during task exit. CONFIG_PROVE_LOCKING This feature enables the kernel to prove that all locking that occurs in the kernel runtime is mathematically correct: that under no circumstance could an arbitrary (and not yet sortingggered) combination of observed locking sequences (on an arbitrary number of CPUs, running an arbitrary number of tasks and interrupt contexts) cause a deadlock. CONFIG_DEBUG_VM Turn on extended checks in the virtual memory system (performance impact). CONFIG_DEBUG_SPINLOCK Built SMP to catch missing spinlock initialization and certain other kinds of spinlock errors commonly made. This is best used in conjunction with the NMI watchdog so that spinlock deadlocks are also debuggable. CONFIG_DEBUG_SPINLOCK_SLEEP Various routines which may sleep will become very noisy if they are called with a spinlock held. CONFIG_LOCK_STAT Enables tracking lock contention points ( see /usr/share/doc/kernel-doc/Documentation/lockstat.txt ). CONFIG_XFS_DEBUG Enable XFS debugging features, including ASSERT checks, function wrappers around macros, and extra sanity-checking functions in various code paths (make a huge and slow code). 

Maintenant, revenez à votre question est-il sûr de les supprimer?

Ces packages sont uniquement à des fins de debugging et ils pourraient provoquer une dégradation des performances. Oui, ils sont sûrs de supprimer et doivent uniquement être installés pendant le debugging.

  • Comstackr / Configurer les options d'un package Yum (RPM)
  • yum ne contient pas le package: libcurl
  • Plusieurs keys GPG identiques. Qu'est-ce qui peut causer cela?
  • Erreur de sum de contrôle Nginx yum sur CentOS5 pour le package CentOS6
  • rpm -Uvh & yum install
  • Comment mettre à jour OpenSSL en utilisant la command Putty et yum
  • Comment installer git to red hat enterprise linux 5.3 x64?
  • Comment Yum avec Red Hat Network Subscription fonctionne-t-il à l'intérieur des images de rhel Docker?
  • yum supprimer l'emballage congélation en effaçant
  • Conflit de dépendance lors de la mise à jour de Yum dans CentOS 7
  • La mise à niveau de la dissortingbution Fedora avec yum distro-sync échoue avec Erreur: versions multilib protégées
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.