Reprise du message précédent :
KRN Bash Completion

En gros, c'est le coup du TAB-TAB pour compléter automatiquement les paramètres.
Au menu il va y avoir :

• Les commandes KRN (bien sûr)
• Les noyaux installés pour les Remove, VerifyKernel et SignKernel
• Les noyaux Custom pour Install, InstallSign et Purge
• Les configs de compilation pour SetConfig, KernelConfig et les ConfComp*
• Les paramètres spécifiques pour SetConfig et Configure

Pour une installation facile et supportant les montées de version, je préconise : « krn Configure »

KRN 9.1 Beta
 

• Bash auto completion disponible (Cf post précédent) sous github
• Auto Completion : Gestion des versions présentes dans le workspace pour Install, InstallSign et Purge
• Amélioration de 30% de la vitesse de listing du workspace

Pour la prochaine version ... nouvelle présentation de la fonction de recherche

Bon, j'ai foutu toute la couche BashSimpleCurses au panier ... ça consommait trop de CPU (1 à 2 minutes supplémentaires sur les compils) et je n'étais pas satisfait des glitch de rafraichissement.
Bref, je me suis développé un moteur d'affichage qui ne fait que les IO nécessaires (même principe que watchfreq) et qui consomme beaucoup moins de CPU.

Il me reste un dernier point à traiter : redimensionnement de la console utilisée (konsole, gnome-terminal ou xterm) afin de forcer un refresh complet

KRN 9.1 out !

Opération obligatoire :

• krn Configure
• Les 2 binaires ont été compilés en amd64 avec gcc 14.1. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Bash completion : toutes les commandes krn sont prises en charge ainsi que leur paramètres optionnels. Les noyaux installés, ceux dans le dépôt ainsi que les configurations de compilation sont pris en charge en fonction de la commande et de la position du paramètre de commande. Tous ces mécanismes fonctionnent également avec le « Detach », le nouveau « Curses » et leur combinaison.
• krn Configure : installation et mise à jour automatique du mécanisme de complétion bash
• krn Watch ... : rafraîchissement descendu à 5 secondes.

• Base de données à mise à jour optimisée : modules des noyaux installés, objets du dépôt KRN (KRN_WORKSPACE)

Ces base de données permettent d'améliorer le fonctionnement de :
- krn List [force] : réduction de la consommation CPU, (avant 200ms, maintenant 80ms)
- krn Purge : réduction de la consommation CPU
- krn Search : nouvelle version croisant avec le contenu du dépôt et agrémenté de statistiques de fin de traitement.
- krn Watch ... : Rafraichissement passé de 10 secondes à 5 secondes

Exemple du nouveau « krn search »

• Commandes type APT : mise en place de nouvelles commandes

- krn Update : création et mise à jour d'une base de données de toutes les version Kernel accessibles à l'outil. Un contrôle des noyaux installés permet de détecter les éventuelles nouvelles versions.
- krn Upgrade [RC] : Cette commande détecte les nouvelles versions Kernel disponibles et propose les commandes pour l'installation de la dernière version : Dépôt KRN, PPA Kernel Ubuntu (en mode DEBIAN) et compilation des sources. Sans le paramètre optionnel, la dernière version stable est proposée, avec le paramètre optionnel la dernière version en RC est alors proposée.
- krn AutoRemove : Suppression automatique des noyaux installés sauf des 2 derniers.
- krn AutoClean : Purge du dépôt de toutes les versions de noyau non installé. Les configurations de compilation ne sont pas concernées par ce nettoyage.

• krn Curses ... : Ecran de suivi de traitement (tour de contrôle) *** Mode DEBIAN seulement ***

Cette approche permet visualiser les étapes de traitement de la commande KRN lancée. Chaque étape dispose de son statut et de son temps d’exécution. Le temps d’exécution de l'étape en cours est rafraichit toutes les secondes.
il est possible de combiner un « Curses » avec un « Detach », par exemple : krn Detach Curses Compile ...
L'auto-completion fonctionne pour toutes les commandes et leur différentes combinaisons.

Seules les commandes suivantes sont prises en charge par « Curses » :
- Compile
- CompileInstall
- CompileSign
- CompileSignInstall
- ConfComp
- ConfCompInstall
- ConfCompSign
- ConfCompSignInst
- GetSource
- Install
- InstallSign
- Remove
- Sign

Exemple (combiné avec Detach)

Nb : pour les autres mode / type de distros, je reste à dispo des personnes souhaitant tester

Fonctionnalités à tester

• BETA : Gestion des noyaux signés en mode REDHAT

Il a l'air sympa ton KRN, TNZ .
Après, personnellement, j'en ai pas l'intérêt, mais sait on jamais, si je passe sous une distribution type Debian un jour (ça sera sid dans mon cas).

Voici les modes pris en charge :

ils n'ont pas tous l'ensemble des fonctionnalités plus ou moins avancées (signature à la compilation, tour de contrôle) faute de testeurs.
Si des envies de ... ?

Le nombre de sources / version packagées est impressionnant !
 

C'est vrai que tu fais cela bien .

Sortie de Linux 6.9.3 ... une p'tite capture d'une compilation en cours

Les commandes affichées sont passées par l'auto-completion.
La saisie (en gras) est plutôt :

• « krn wa ls »
• « krn gs 6.9.3 »
• « krn dt cu kccsi 6.9.3 config-6.1-Ryzen »

Je commence à regarder ton outil, tu ne fais plus de tag et tu ne fais pas de branche sur le git?
Pas super pratique pour être sûr de prendre la même version ou d'être sur d'être sur la version stable.

EDIT: il y a une doc quelque part pour savoir comment le compiler?
Parce que dans le repo dans last il n'y a pas le binaire kern.
On l'obtient en compilant dans src?

EDIT2: ok je suppose que c'est un des script genre "Compile_DEBIAN.sh" si je veux juste le compiler sans l'installer?

Coucou
Le plus simple est de prendre l'archive :

Mais bon, si tu as pris avec un git clone, la commande manquante est : ln -s /Répertoire/de/krn/Main.sh /Répertoire/du/PATH/krn
Puis ensuite une fois la commande krn opérationnelle :

PS : pour l'autocompletion, une fois krn installé et configuré, il faut fermer le terminal et en ouvrir un autre qui utilisera les mises à jour faites à .bash_completion

Hello.
Merci pour l'info.
J'avais vu le zip mais j'aime bien voir ce que j'utilise donc j'essayais de repartir des sources vu que c'était marqué partout
 
Je regarde tout ça merci.

Oui, mais les scripts fonctionnent avec plein de variables montées par le Main.sh
Le premier post du topic est mis à jour avec l'histoire du « ln -s » ... et n'oublie pas les pré-requis ... très souvent bc n'est pas installé de base

ça semble assez clair, je devrais m'en sortir maintenant.

Bon compilation en cours.
Je pense qu'il manque une petite doc simple sur l'enchainement des cmd quand on veut compiler.

Par exemple sauf erreur de ma part, je n'ai pas trouvé de cmd permettant de lister sur kernel.org la dernière version de kernel genre LTS ou autre non?
Faut donc bien manuellement allez sur le site regarder la version puis faire un ./krn CC 6.6.41?
( ou CCI si on veut installer en même temps)

D'ailleurs quand tu installes tu installes quoi? Le kernel + les headers + libc?

EDIT: compilation terminée, je n'ai pas vu non plus s'afficher la durée de compilation? ça pourrait être utile aussi.

EDIT2: la compilation s'est foirée, par manque de place sur l'espace de compilation.
Pour le coup l'outil ne remonte rien
Les seuls logs que j'ai:

Il a fallut que je regarde dans Make-2-bindebpkg.log pour voir que:

Faut que je regarde comment changer le répertoire de travail parce que "/dev/shm/Compil-6275" (donc en mémoire vive si je ne me trompe pas) ce n'est pas une superbe idée.
Et pourtant j'ai 32go de ram donc ça va poser problème à énormément de monde.
Et j'ai pourtant bien configuré le répertoire KRN_WORKSPACE.

C'est bizarre cette histoire, tu n'est pas le 1er avec 32 Go de RAM à avoir des soucis avec le /dev/shm ... sur mes KDE Neon / Ubuntu LTS le /dev/shm tourne avec 50% de la RAM, soit 16 Go et je peux lui enquiller 2 compils simultanément. Pourtant l'espace disponible dans /dev/shm est contrôlé avant !?

Pour compiler sur le DD, met le MIN TMP FS à la valeur de ta RAM (en Mo) comme dans l'exemple ci-dessous :

Avant de dégager le contenu du répertoire work y avait bien 16go de pris dans shm.
Ok je testerais ton réglage.

Pour info, ce n'est pas une bonne idée de passer par emacs pour ouvrir le fichier de conf. N'est-il pas possible d'utiliser l'outil par défaut?
Ou alors plutôt utiliser vi/nano ça c'est sûr que c'est présent.
(oui j'ai pas emacs pas besoin )

En fait, ça passe par l'éditeur par défaut porté par la variable standard EDITOR
Allez, pour la prochaine version, je mets « vi » pour les masochistes.

KRN 9.2 out !

Opération obligatoire :

• krn Configure
• Les 3 binaires ont été compilés en amd64 avec gcc 14.1. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Versioning Archive vs Build : il y a toujours eu un flou dans la gestion des premières versions Linux (x.y versus x.y.0) présent également avec les RC. Bref, j'ai tout mis à plat. Le programme linux-version-archbluid prend une version ou un ckc-version-libellé en paramètre et affiche 3 variables KRN_LVBuild, KRN_LVArch et KRN_LVCkc contenant le format correspondant. Ces variables sont sourcées pour être utilisées au bon endroit. Conséquence directe, le « krn list » affiche et gère en fonction des versions Build (donc avec le .0 y compris pour les RC).

• Taille des build : en fin de compilation et avant de tout nettoyer, les logs fournissent la taille de l'espace disque utilisé par le build. Cette information permet de définir la taille minimum pour effectuer une compilation en TMPFS au lieu d'utiliser le disque physique. Le paramétrage de cette variable se fait via « krn configure edit » et la variable est « KRN_MINTMPFS ». Sa valeur par défaut est 5120 Mo (5 Go) mais elle n'est pas forcément adaptée à tout le monde. Je recommande de la mettre à la valeur de la RAM présente sur la machine. La valeur adaptée sera fournie par une compilation sur disque physique.

• krn upd et krn upg : Mise en place des raccourcis afin d'éviter de faire appel à l'auto-completion de manière systématique.

• krn configure edit : Utilisation de l'éditeur défini avec $EDITOR sinon utilisation de « vi ». (perso, je suis plutôt emacs)

Deux fois la même chose?

corrigé

Un p'tit post pour la sortie de la 6.10.3 et de gcc 14.2
 
Je suis tombé sur la sortie de la 6.10.3 (à 9h01) avant qu'elle n'apparaisse sur la page principale de kernel.org, du coup, la version Ubuntu pas encore dispo :  

Exemple de mise à jour simplifiée après avoir transféré les paquets depuis le 5950x sur le pcdutaf (7840u) :

Perso je me suis fais un script bash pour ce que je fais ça me suffit largement.

P'tain ... j'suis en train de me battre avec une Fedora pour la mise au point du mode REDHAT.  
Plus ça va, plus je me dis que je suis content d'utiliser du Debian based. Quelle merdier les RPM !
 

• la gestion de dépendance est tellement moisie que les 3/4 des outils de compilation sont désinstallés quand on supprime un noyau
• l'outillage appelé par les Makefile Linux pour fabriquer les RPM est tellement rigide qu'il n'est pas possible de générer des RPM avec un noyau signé avec sa propre signature. Cela va finir en mode bzimage tellement c'est naze.
• si la Fedora montre trop de difficultés, j'vais p'tet tenter une AlmaLinux.

Et OpenSuse, tu n'y penses pas ?

Finalement, j'y suis arrivé ... en modifiant un Makefile du noyau au bon moment.
Ceci dit, je supprime une regénération des paquets dans l'histoire
Maintenant, va falloir tester que c'est compatible DEBIAN tout ça

Je viens de faire une validation du mode Debian de la 10.0 Alpha et j'ai pu régler quelques soucis de récupération des paqutes locaux lors d'une build custom.
C'était nécessaire pour valider la nouvelle architecture logicielle de l'outil. J'ai fait une grosse factorisation des différents couples mode / commande.  
 
Prochaine étape, montage d'une VM Arch Linux pour valider l'existant et créer la génération des paquets pacman pour les Linux 6.11

Juste pour le fun :

La commande passée dans la Fedora :

PS : je me suis fait un fichier de config de compilation avec tous les CONFIG_DEBUG_* à « n » ou « Not Set » afin d'avoir un répertoire de build tournant entre 5 et 6 Go au lieu des 25 Go avec les symboles de debug.

Je viens de me monter un ArchLinux en VM ... Effectivement, on est sur du advanced user avec ArchWiki ouvert sur le côté. Par contre, très réactif, pas de gros soucis de gestion de dépendances pour l'instant.  
Je me demande si je ne vais pas me faire une installation native à côté de KDE Neon
 
L'idée est surtout de mettre au point la génération de paquets Arch disponible à partir de Linux 6.11

Gestion des paquets Arch en cours de mise au point !

Dans l'ordre, en mode ArchLinux, nous avons :  
 
1. la gestion de compilation custom des paquets Arch
2. un noyau signé à la compilation
3; avec les modules signés associés
 

KRN 10.0 out !

Opération obligatoire :

• krn Configure
• Les binaires ont été compilés en amd64 avec gcc 14.2. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Refonte de l'architecture logicielle : Suppression des bouts des scripts quasi identiques entre les modes. J'ai factorisé le plus possible et transféré les instructions spécifiques de chaque mode dans des « modules » à part chargés suivant le mode utilisé. Pour le mode ARCH, j'ai introduit un principe de surcharge de fonctions qui se déclenche par rapport à la version de noyau manipulée. A partir de la version Linux 6.11, il est possible de générer directement des paquets administrables par l'outil « pacman ». La surcharge de module krn sert à la gestion des paquets pacman du mode ARCH.

• Paquet KRN : Une compilation standard d'un noyau pèse aux environs de 5 Go (sans DEBUG) avant nettoyage. Après, cela redescend autour des 3.9 Go, ce qui est encore assez important en termes de consommation d'espace de stockage. C'est pourquoi ce type de gestion de noyau passe par une compression zstd et fabrique une archive d'un nouveau type : krn.tar.zst . Ces paquets tournent autour des 450 Mo à la sortie. En fouillant les options zstd, peut être qu'il est possible d'augmenter le niveau de compression. Bref, seuls les modes ARCH-CUSTOM et ARCH (jusqu'à Linux 6.10 inclu donc) utilisent ce format de paquet.

• Mode ARCH et ARCH-CUSTOM : Ces modes sont maintenant stables. Les fonctionnalités nouvelles sont : signature du noyau à la compilation, gestion des config custom, tableau de bord des suivis de traitement (curses). Le nommage des noyaux a été également revu et expliqué dans l'aide en ligne. ARCH => linux-upstream, ARCH-CUSTOM => linux-x.y.z[rc?] ... Ah oui, dernière petite chose, le fichier config de base de la distrib' a plein de variables CONFIG_DEBUG_*=y ce qui a pour conséquence une compilation très longue et une consommation de l'espace de stockage pouvant aller entre 20 et 25 Go. Ma recommandation est de se faire une copie de la config de base et de passer manuellement toutes les variables CONFIG_DEBUG_* à n.

• Mode REDHAT : Ce mode est maintenant stable. Les fonctionnalités nouvelles sont : signature du noyau à la compilation, gestion des config custom, tableau de bord des suivis de traitement (curses).

• Mode GENTOO : Resté trop longtemps en mode Beta voire Alpha et aux vues des multiples possibilités de configuration / gestion proposées par cette distribution, j'ai préféré carrément supprimer ce mode d'autant plus que Gentoo étant une rolling-release, les dernières versions de Linux doivent tomber quelques heures / jours après leur publication. Ce dernier point rend krn moins intéressant dans ce contexte.

• Signature kernel à la compilation : Optimisation du nombre d'étape et de leur temps d’exécution CàD 21 / 22 minutes avec krn9.2 et 14 / 15 minutes avec krn10.0 ... soit un gain de 6 à 7 minutes pour les modes demandant une génération de paquet (deb, rpm, pkg.tar.zst)

• Tableau de suivi des traitements (curses) : Optimisation de la gestion du curseur et du rafraichissement de la « fenêtre » de la log de la commande en cours. (je réfléchis à une amélioration pour passer le rafraichissement d'un mode cyclique à un mode temps-réel / évènementiel)

• krn watch : Optimisation de l'affichage du curseur et de la « dérive » horaire du rafraichissement.
• krn search : Prise en charge des paquets KRN

Ayé, j'ai fini de réfléchir et la version 10.1 va subir l'épreuve du feu cette semaine.
Le rafraichissement des tableaux de bord sont maintenant plus réactifs : dès qu'un évènement intervient, l'affichage de l'information est fait directement sans attendre de timer.

Pour la petite histoire, j'ai remplacé la lecture de fichiers (messages de statut, heures de début et fin des étapes) par une lecture en continue d'un pipe nommé (fifo). Le programme C a été ajusté pour interprété chacun des messages reçus pour ne faire que les opérations nécessaire et ainsi réduire l'overhead CPU inhérent à la gestion des tableaux de bord.

KRN 10.1 out !

Opération obligatoire :

• krn Configure
• Les binaires ont été compilés en amd64 avec gcc 14.2. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Tableau de suivi des traitements (curses) : Rafraichissements gérés en temps réel, suppression des instructions non nécessaires pour optimiser la consommation CPU et quelques améliorations cosmétiques.

Perso, j'aime beaucoup, ça enlève le côté pachydermique des rafraichissements cycliques

KRN 10.2 out !

Opération obligatoire :

• krn Configure
• Les binaires ont été compilés en amd64 avec gcc 14.2. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Tableau de suivi des traitements (curses) : Intégration des appels de scripts bash dans le binaire d'affichage (trailer de la log de traitement) et conversion du script de gestion du timer en binaire. Ces 2 changements permettent d'obtenir plus de fluidité et un gain CPU de l'ordre de 5 à 10% ... qui pourra servir aux compilations monitorées.

KRN 10.3 & 10.4 out !

Opération obligatoire :

• krn Configure
• Les binaires ont été compilés en amd64 avec gcc 14.2. S'ils ne sont pas compatibles avec l'OS hôte :

L'aide en ligne est à jour sur le 1er post.

• Mode ARCH : La génération des paquets pacman ne peut pas être faite avec le compte root
• krn Curses : blocage des commandes de signature de noyaux quand un mot de passe est utilisé (pas de saisie interactive)
• krn SignModule : gère maintenant par fichier ou par nom de modules (via la completion) et signe les modules compressés (zst ou xz)
• krn Sign : signe les modules compressés (zst ou xz)

tu maintiens la recherche sur le mainline ubuntu ou tu supprimes ? Je crois qu'au bout de 2 mois, on peut dire que c'est mort

Il faut que j'aille voir ce qu'il se passe ... ils ont p'tet changé la gestion des arborescences.

Edit
y'a plus rien après la 6.11.0 ... je vais laisser en place pour ceux qui voudraient jouer avec des vieilles versions.
Ceci dit, je réfléchis à détecter et lister les corrections de CVE dans la commande ChangeLog et aussi à corriger un bug sur la suppression des modules.
Ah oui, tiens, y'a un autre truc qui me travaille, c'est la prise en charge de la version linux-next.