web-dev-qa-db-fra.com

Mettre fin à la panique du noyau en ne synchronisant pas la mémoire et en évitant les processus meurtriers

J'ai dans VMWARE un ordinateur virtuel, Lubuntu17-32bit , il peut fonctionner sur 500mb RAM facilement (même 300mb suffisent ). J'ai compilé un noyau "linux-4.12.3.tar" et l'installé à l'intérieur du VM c'est-à-dire Lubuntu. Quand j'ai redémarré avec le nouveau noyau, je reçois:

End kernel panic not syncing out of memory and no killable processes

Je devais augmenter le RAM du VM till 1500mb pour éviter cette erreur et lorsque le système se lancait et atteint le bureau, j'ai vérifié l'utilisation de la mémoire, il est identique à précédent 300mb .

Remarque: le disque dur affecté à cette machine virtuelle est sata 40 Go .

Alors, pourquoi tout cela RAM est-il nécessaire !! et le plus important, comment puis-je réduire cela?

Mise à jour:

Veuillez noter les gars: je ne dit pas que j'ai eu des problèmes de compilation, d'installation, ni de travail sur le nouveau noyau. Le seul problème concerne le démarrage à partir du nouveau noyau; il ne nécessite que 1 500 Mo pour le démarrage. Lorsque le démarrage est terminé, il atteint l'écran de connexion et le bureau. Le système d'exploitation (Lubuntu) nécessite au total moins de 300 Mo. Alors pourquoi ce 1500mb et comment le réduire?

Réponse:

Le fichier /boot/initrd.img était le problème, il a une taille énorme. Pour réduire sa taille:

cd /lib/modules/<version>
Sudo find . -name *.ko -exec strip --strip-unneeded {} +
Sudo update-initramfs -c -k <version>

Redémarrage

Merci pour les gars qui l'ont signalé.

kernellubuntu
2
Mosab Shaheen

Je suppose que la panique du noyau est survenue pour l'une des raisons suivantes ou peut-être plus

1 . Compiler le noyau, c'est installer le noyau, donc au lieu de remplacer l'ancien noyau, il est resté bloqué dans une impasse où aucun des noyaux n'a pu utiliser la mémoire, donc la panique.

  1. Le nouveau noyau est entré dans une sorte de boucle, pensez-le de cette façon "il a essayé de s'appeler lui-même" ou tout simplement il est devenu un type de bombe à retardement et donc une erreur de mémoire insuffisante et une panique.

  2. La partition allouée pour le nouveau noyau n'était pas suffisante. Essayez de créer une partition différente, montez-la, reliez-la de manière à ce que d'autres programmes puissent l'exécuter. Maintenant, recompilez-le avec gcc et chaines (linker)

  3. Au lieu de remplacer le noyau, il s'est tué.

  4. Si vous extrayez une archive de noyau d’une taille initiale de 300 mb, après extraction, c’est-à-dire "tar -xvf kernel.Zip", elle devient un géant de 900 mb. Après avoir installé des paquets tels que gcc, g ++, gnu-make, etc., et les avoir compilés, le noyau compilé peut devenir un mamoth de 2 Go d’espace. Donc, si la partition n’a pas beaucoup d’espace mémoire, cela peut se produire.

  5. Vous n'avez pas fourni de zone d'échange. La construction d’un noyau nécessitant une grande quantité de ressources, elle nécessite à la fois une bonne quantité d’espace, un swap et une RAM.

  6. Pendant l'installation, il crée un sous-dossier tel que/mount,/proc,/boot,/dev, etc. Pour que chaque partie obtienne son emplacement respectif, dont certains ont échoué en raison d’un manque de mémoire.

  7. Généralement, un noyau est compilé en chroot comme environnement, mais si le chroot n’est pas correctement défini, il peut échouer dans l’obtention d’une ressource comme proc, mnt, dev et donc la panique.

    Si vous avez encore besoin d’aide, vérifiez ces deux emplacements # 1 équipe du noyau pour Ubunt , # 2 équipe du débogage du noyau pour Ubunt

Nouvelle mise à jour:

Comme votre mise à jour semble impliquer la compilation du noyau a fonctionné.

Cela pourrait seulement signifier que vous avez compilé le noyau entier.

Habituellement, un noyau contient tout ce qui peut être important pour l'un, mais une perte de temps et d'espace pour l'autre.

Donc, vous pouvez aussi utiliser les nouveaux noyaux de noyau Ubunt . Dans mon cas, c'est v4.14-rc1.Téléchargez le noyau qui correspond à votre Arch. J'ai x86_64 donc je choisirais un 64 bits. Je téléchargerais ces

  • linux-headers-4.14.0-041400rc1_4.14.0-041400rc1.201709162031_all.deb
  • linux-headers-4.14.0-041400rc1-generic_4.14.0-041400rc1.201709162031_AMD64.deb
    • linux-image-4.14.0-041400rc1-generic_4.14.0-041400rc1.201709162031_AMD64.deb

et émettrait alors "Sudo dpkg -i * .deb" pour tout compiler.

Maintenant, il semble que le noyau que vous avez compilé ait une taille supérieure à 1 Go et utilise donc plus de ressources.

Le noyau ubuntu a de nombreuses parties supprimées, donc sa taille est faible et utilise une compression importante.

Votre noyau peut tout contenir et peut être utilisé par IOT, des serveurs, des ordinateurs de bureau et peut être compatible avec arm 64, AMD64, etc., car il peut contenir tous les modules nécessaires à leur exécution.

Donc, pour le réduire, vous devez supprimer toutes les pièces inutiles de votre cas, comme des pilotes de matériel dont vous n'avez jamais entendu parler. Dénuder les composants du serveur lorsque cela est possible.

En passant, la compilation du noyau est un travail fastidieux, car elle utilise beaucoup de ressources, de temps et de patience.

Mise à jour # 2:

Comme vous l'avez mentionné, votre fichier initrd.img était énorme. Pourriez-vous au moins publier une capture d'écran de votre/boot/ou utiliser Terminal "ls -l" pour lister la taille de tout.

Le noyau se trouve être le coeur de toute distribution Linux. C'est très complexe, donc sans rien savoir, on peut deviner quel est le problème.

Je vous suggérerais néanmoins de supprimer les modules indésirables de votre noyau, puis de le compiler.

2
SIDDHARTH