Reprise du message précédent :
Je sais que je réponds avec trois semaines de retard, mais au cas où ça intéresserait des gens...

Il n'y a pas de raison de faire la compilation en root, on peut utiliser fakeroot pour les moments où il faut faire semblant d'être root pour la création du paquet debian.

Je viens de faire un tour dans le README qui est dans les sources pour y chercher autre chose et je vois qu'il est déconseillé d'utiliser /usr/src/linux pour les sources :

Par contre on peut utiliser par exemple /usr/src/linux-2.6, /usr/src/linux-2.6.32... même si je ne vois personnellement pas l'intérêt de mettre les sources là plutôt que dans /home/login.

Pour suivre la version de développement c'est plus simple d'utiliser git, par exemple pour suivre le noyau de Linus :

pour créer le répertoire initial (ça télécharge plusieurs centaines de méga-octets), puis à chaque fois qu'on veut mettre à jour il suffit d'aller dans le répertoire et de faire

 
 
Pour savoir où on en est :

qui renvoie par exemple pour moi v2.6.33-rc2-268-g45d28b0.
 
 
Je suis au 268e commit après le tag v2.6.33-rc2, si je veux revenir à la version 2.6.32 je fais

et pour revenir où j'étais

Je ne suis pas convaincue que ce soit utile, chez moi le gouverneur est ondemand, et évidemment au début de la compilation le processeur passe à la vitesse maximale, mais au bout d'un moment la vitesse diminue et au lieu d'avoir « hardware limits: 800 MHz - 1.60 GHz » dans cpufreq-info, je n'ai plus que « hardware limits: 800 MHz - 1.33 GHz », puis seulement 1.07 GHz et enfin 800 MHz comme fréquence maximale. L'utilisation d'un autre gouverneur n'y changerait rien puisque c'est une limitation du hardware (probablement pour éviter la surchauffe).

Comme dit au-dessus, utiliser fakeroot, et puisque j'étais dans la lecture de README, il y a l'option "O=output/dir" qui permet de mettre tous les fichiers objets dans un répertoire différent de celui des sources et donc d'éviter de compiler en étant root même si les sources sont dans /usr/src, mais je ne sais pas si ça marche avec make-kpkg.
 
 
On peut aussi compiler simplement avec « fakeroot make deb-pkg » pour obtenir un paquet debian (avec le noyau et les modules mais pas les headers) ; on peut mettre les scripts qui vont bien dans /etc/kernel pour mettre à jour grub, générer l'initramfs,... pour que tout ça soit fait automatiquement quand on installe ou désinstalle un paquet créé de cette façon (make-kpkg utilise aussi ces scripts depuis la version 12).

1) Je compile à partir d'un dossier sur lequel seul root à les droits en écriture, je n'irais pas loin avec fakeroot. Mais si tu veux le faire depuis ~/ avec fakeroot et sudo dpkg, libre à toi.
2) /usr/src/linux n'existe que parce que je l'ai crée (ce n'est qu'un symlink). Les modules tierces que je compile sont parfaitement heureux avec les headers (complets) de mon kernel-du-jour.
3) Pourquoi pas ? J'ai une connexion belge avec un quota mensuel ridicule. La méthode manuelle consomme bien moins de bande passante.
4) C'était un workaround pour le manque de réactivité de ondemand sur ma machine en 2007 qui n'a plus lieu d'être aujourd'hui. Cela dit, si ta machine baisse sa fréquence en pleine charge, c'est un bug ou une magouille bios du constructeur pour économiser sur le système de refroidissement (laptop, je suppose).
5) On peut le faire d'un tas de façons. La mienne a fait ses preuves depuis 200 ou 300 noyaux et me prend moins de 2min en temps humain.

D'un point de vue pédagogique, je trouve que c'est bien de dire qu'on est pas obligé d'être root pour compiler et qu'on peut utiliser un autre répertoire que /usr/src.
 
En somme d'expliciter les choix personnels dans la procédure.

Phoronix a quelques problèmes avec du ext4: http://www.phoronix.com/scan.php?p [...] &px=Nzk0OA

J'ai vu ça hier soir, je pensais que ces soucis étaient derrière nous
 

Possible, ils vont retenter l'expérience et voir si ils perdent plus ce coup ci.
D'un autre coté, c'est pas plus mal si ca permet de combler un trou dans ext4

2.6.33: http://www.phoronix.com/scan.php?p [...] &px=ODAxMg
 
Y a plus d'excuses pour les ssd \o/

Compil en cours  

Comme à chaque release, le pavé de Patrick_G, toujours aussi intéressant  
 
http://linuxfr.org/2010/02/25/26478.html

 
Bon, des retours sur la mise en pratique du trim ?

http://www.h-online.com/open/news/ [...] 14669.html
La partie dédiée au TRIM
(Ou en français dans le numéro de Mars de GNU Linux Magazine France, dans la première partie dédiée au nouveauté de Linux 2.6.33)

Bonjour à tous. Je n'ai pas eu de succès sur le topic Arch, donc je tente ici :
 
J'ai une question technique.
 
J'utilise Arch sur un Toshoba Satellite U500. Ca marche pas trop mal à quelques détails près, dont celui qui m'amène à poster.
Les controles de luminosité de l'écran fonctionnent, mais pas tout à fait comme il faut.
 
En théorie (et sous Windows), je vais de la lumosité minimum et la luminosité maximum en 8 "étapes".
 
[moi@portable-6 ~]$ cat /proc/acpi/video/IGD/LCD/brightness  
levels:  25 35 45 55 70 80 90 100
current: 55
 
Sauf que sous Arch, je fais des sauts plus importants. Je passe du minimum pour atteindre le maximum en cinq étapes.
 
En gros, en remontant, je fais 25 -> 45 -> 70 -> 90 -> 100
 
Ca m'aggace un peut.
 
Quelqu'un a-t-il idée d'une façon de régler celà ? (je suis près à recompiler un kernel)
 
Détail amusant : le comportement est bon quand j'utilise le CD d'install. Ca déraille une fois l'install faite.
 
Merci !

2.6.34 out

Je dirais même:

Frimeur  

Bien sûr, à lire comme d'hab :
http://linuxfr.org/2010/05/17/26852.html

Déjà disponible dans les dépôt testing d'Archlinux

http://lkml.org/lkml/2010/8/1/188  
 

J'ai mis à jour rapidement le premier post. WedgeAnt, encore la volonté de suivre un peu ou tu préfères passer la main ?
 
Quelqu'un volontaire pour reprendre ?

Il est en vacances là

J'oubliais, un nouvel outil fait son apparition:

à la place de l'habituel "make menuconfig" on a le droit à un "make nconfig" en ncurses.

Je préfère le menuconfig !
Sinon, petite question à propos de l'option barrier sur un système de fichier ext3 : comment l'activer ?
Je ne sais pas si c'est par défaut, mais en tout cas, barrier=1 dans mon fstab ne change rien au montage, je dois oublier quelque chose quelque part (bios, kernel ?) ou alors, mes disques durs ne sont pas adaptés (cf ma config).
 
edit : en 2.6.35, j'ai donc cela

Elle existe cette option pour ext3 ?
 
EDIT : ah oui

Oui, d'après ce que j'ai vu en regardant ici.
 
edit : ok, j'ai vu que tu as vu !

Par curiosité, comment faire pour construire un kernel simplifié (mais fonctionnel pour une machine donnée) ?
Faut-il jouer avec dmesg/lspci/lsusb/lshal/modprobe pour avoir le listing des choses utiles ou y a-t-il plus simple ?

La partie hardware est simple, surtout si tu pars d'un kernel existant. La difficulté vient des besoins imposés par le userspace.  
Un truc absolument sans intérêt pour toi peut quand même être obligatoire sous peine de planter un script de ta distrib. Le programme que tu vas installer dans 3 mois peut avoir été compilé avec le support d'une option que t'as retirée. Il faut aussi faire évoluer les choix d'options en fonction de ce qui est ajouté ou déprécié dans ta distribution à chaque upgrade...
 
Ce sont des choses impossibles à automatiser.

 
make localmodconfig
http://www.cepcasa.info/blog/?p=186
 
ça aide déjà pas mal.
 

 
C'est rarissime un soft userspace qui nécessite une option précise du noyau (à part quelques deamons comme pulseaudio, systemd et encore) et ne peux pas fonctionner sans. Vu la diversité des distributions/saveurs de chaque, ce serait à peu près du suicide.

Bien intéressant

 
Euh, c'est facile de faire une configuration de noyau qui empêche udev ou encore iptables de fonctionner correctement..

 
C'est moins rare que tu sembles le penser.
Parmi les emmerdeurs, on trouve des options de crypto, de netfilter, de pseudo systèmes de fichiers, dm et plein d'autres (compatibilité /proc/acpi, fût un temps c'était NFS et j'en passe. Il y en a des kilomètres). Evidemment, toutes ne sont pas bloquante pour le fonctionnement d'un programme ou de l'OS, mais j'aime pas avoir mon boot rempli de "error bidule cannot find module xxx" ou me retrouver face à 3 pages d'erreurs quand j'update mon initramfs. Plus stupide encore, tu peux te manger des erreurs parce qu'un script cherche le module de l'option X alors que l'as compilée en dur.

Il est évident que si on n'active pas netfilter, on aura du mal à filtrer, ou si on compile pas son noyau avec le support de ext4, il sera difficile de monter une partition ext4. Mais c'est pas un soft qui pose problème, c'est tout le système.

Et même avec ça, le nombre de softs qui nécessitent des options obligatoires dans la config du noyau, c'est rare. Pour faire simple, ce sont les softs qui configurent les modules du noyau ou exportent sa structure interne (udev, iptables, perf, systemtap etc). Après, il y a les trucs recommandés (cgroup pour systemd, certaines options realtime pour jack ou pulse etc) mais qui ne sont pas bloquants, le softs travaille simplement en mode dégradé.

Après, les scripts mal fichus qui détectent n'importe comment, C'est pas un pb de conf noyau ça

 
Le truc c'est que c'est pas aussi simple que d'activer une option :

 
Et des fois, quand on met à jour son noyau, il y a un nouveau CONFIG_NETFILTER_* à ne pas oublier d'activer.
 
Idem pour udev; voilà le README que j'ai du suivre, par exemple :

 
 
(d'ailleurs, ils disent qu'il faut au minimum un noyau 2.6.27 pour cette version d'udev, mais ça n'est vrai que sur x86*. Mon pauvre PowerPC, qui déjà ne boot plus avec un noyau > 2.6.27, doit donc en rester à une version bien plus ancienne d'udev, à moins de patcher )
 
Bref, moi je ne vire une option que si je suis certain qu'elle m'est inutile

Je suis assez d'accord avec la conclusion

 
Cette phrase est très importante. Il ne faut pas non plus oublier de mettre un CD ou DVD dans le lecteur, ne pas oublier la clé usb, la web cam, le dongle bluetooth, etc... Sinon du matériel et des systèmes de fichiers ne seront plus reconnus.
 
Cette option est à voir comme un outil, une aide pour réduire la taille du noyau et le temps de compil'.
 
Perso, je ne connaissais pas. Merci Mjules.

Tiens, je me pose des questions par rapport aux UUID.  
Est-ce que le kernel lui-même les comprend nativement ? Par exemple, pour certaines options dans la config, il est demandé d'indiquer une partition (la partition d'hibernation ou autre) sous forme /dev/sdx. Est-ce qu'il est possible d'y mettre un UUID à la place pour éviter les problèmes de changement de sdx entre les reboot ? Et si oui, sous quelle forme: UUID=xxxxx-xxxxx ou /dev/disk/by-uuid/xxxxx-xxxxx (ou autre) ?

Lecture du matin: http://kernelnewbies.org/Linux_2_6_36

Hop, je viens de passer au 2.6.36, et j'ai vu qu'il y avait des modifications (notamment) avec udev, genre :

vu là.
 
Je suis avec udev-164, et j'ai le message suivant dans le dmesg  :

 
Sinon pour la version de ssh :

 
A priori, j'ai des versions compatibles, mais le message persiste.

Nième sortie de Linus ?
Dev’ *BSD qui se moque du foutoir dans la kernouille ?