Reprise du message précédent :

Le deb est gros s'il contient les headers, ce qui est normal. Mais ca n'est pas le noyau en lui même, cherche vmlinux ou bzImage. La, tu auras la vrai taille de ton noyau.

Grosso modo, nécessaire uniquement s'il faut charger des modules au démarrage qui ne peuvent être chargé autrement (genre, les modules de support raid5 sont sur une partoche raid5, c'est ballot pour aller le chercher...)

Le .deb c'est pas le noyau, c'est un paquet debian. Rien à voir avec ton noyau en temps que tel.

Si c'est la taille de ton paquet qui te gêne, alors dit le comme tel; mais ne dit pas que c'est le noyau, sinon, on comprend rien

je viens de mettre le 2.6.21.1, ca boote plus, il retrouve pas ma partition / sur /dev/sda5
 
Y a eu du changement ?

A coup sur, t'as le driver du controleur qui a du sauter dans ton passage  

Il a l'air assez mouvementé le passage à cette version.  

Surtout si on la fait à la main, sans attendre les paquets de sa distro

Je le fais toujours à la main.

Bon j'ai un peu mis a jour le premier topic et rajouter des liens vers deux topics interressants, d'ailleurs si Thrak pouvait enrichir le premier post de son topic
Une idée interressante serait aussi de créer un topic sur grub/grub2/lilo & autres bootloaders.

C'est encore vivant lilo? Ca fait un bail que je ne l'utilise plus...

Vouais, ils sont repassés en /dev/hdX pour les disques en PATA ... donc faut éditer ton grub et ton fstab avec /dev/hda5.

Ah bon? Moi avec mon disque durs IDE sur chip JMicron, c'est toujours /dev/sda sous noyau 2.6.21  

je ne me sers que de grub en ce qui me concerne, ceci dit le post était dans un but exhaustif.
Tu te sens interessé pour maintenir ce genre de topic?

Celui sur lilo? Non

Ah tiens, si tu veux rajouter un lien:

http://www.advancedlinuxprogramming.com/

Très bien, j'y ai appris plein de choses

Notez que certaines parties ne sont pas spécifique à linux, mais plutot, de bons réflexes de programmation, et du posix (ca peut aider sur des *BSD aussi).

Erf ! Donc c'est vraiment le bordel ce noyau

par liens j'ai simplement rajouté des liens vers des topics existants.

Ben il existe les nouveaux drivers PATA intégrée à libATA (et donc les disques sont nommé /dev/sdX) et les «anciens» drivers PATA/IDE (-> /dev/hdX) moi depuis que je suis passé en Core2 Duo, j'ai pratiquement utilisé que les nouveaux drivers PATA   (enfin au début j'avais de problème de compatibilité entre grub et le BIOS JMicron, obligé de passer par LILO, etc etc)

C'est pas ça.
Sous Debian avec le 2.6.20, il y a eu ce passage avec les disques PATA reconnus comme du SCSI (donc /dev/sdX).
Seulement il y a eu une MAJ du 2.6.20 où les disques PATA (du moins les miens) sont de nouveau reconnus comme de l'IDE (donc /dev/hdX).
Bref, c'est casse-couille.
 
Par contre je ne sais pas si ça vient de corrections de Debian ou de la Kernel Team.

Ben moi je pense que c'est plutôt de Debian moi je suis sous Gentoo et pas de changement du coté de l'identification des disques durs avec libATA  

 
Oui c'est probablement cela, mais encore une fois je cherche la raison la plus bas possible
Merci

C'est pas que Reiser4 modifie le fonctionnement du VFS, et donc il a besoin d'attaquer directement dans le code du noyau ? (j'entends par là que c'est pas un "simple" module)

ok je vois ce que tu veux dire, on patche le kernel on ne fait pas qu'un ajout.
 
C'est une possibilité intéressante je regarderai rapidement les différents patchs ce soir si j'ai le temps.
 

ton topic sur l'optimisation du kernel.
Un petit rappel en premiere page de nos discussions sur les schédulers par exemple

Hello
 
Est ce que quelqu'un sait comment voir si gcc compile avec des options de débogage ? (option -g) Car se sont mes modules qui sont d'une taille énorme, et non mon noyau.

Fait voir la taille des .o et .ko .

Je te dirais ceci plus tard. Mais ils sont plus gros que la normal.
J'ai relancer une compilation avec dans le make menuconfig => Kernel Hacking => Compile the kernel with debug info décocher.
 
PS: j'ai installer une debian (en 486 lol) sur une machine virtuel, et là la compilation à une taille normal. Et Compil the kernel with debug décocher. Donc je test.....

Bon, j'ai trouver. C'était bien Compile the kernel with debug info de cocher qui me sortait un .deb de 182Mo. Là il fait 19Mo.
 
je me demande pourquoi Ubuntu coche ses options par défaut.

moi aussi d'ailleurs, à moins que tu sois en version instable, pas de raison.

 
C'est Debian, y'avais de l'overleap entre les anciens module et les nouveau (libata) sur certain driver.  
Faudrait penser à passer en label ou en uuid heiin

Voui je sais, j'utilisais les labels, mais j'avais un problème lors de l'activation du swap
Faudrait que je revois ça.

faut que tu refasse un coup de mkswap avec les bons flags
 

 
PS: Ne pas oublier de le faire dans grub et dans les hook initramfs (pour le suspend)

Tu pourrais me montrer ton fstab en entier stp ?

Je pense pas que le commentaires et les lignes vides puissent t'éclairer

Je devais pas parler de la même chose que toi en ce qui concerne le label.
Moi le parlais de /dev/disk/by-*
 
Je ne connaissais pas la syntaxe de ton fstab, je vais me renseigner.

Moé ça c'est de la magouille udev, ca daube un peu
 
Une piste:
http://doc.ubuntu-fr.org/uuid_et_label

Han, ouais, effectivement c'est vachement mieux
 
Je te laisse imaginer la gueule de mon fstab avec le bouzin dont je parlais ...
 
Merci beaucoup.

Je suis en noyau 2.6.20-15
 

 
L'option dans le .config est

 
Se qui est bizarre, vu que le noyau qu'on download via apt-get ne fait pas du tout 182Mo  

Un article d'avant hier, également : http://www.debian-administration.org/articles/522

Hum, pour les gens en reiserfs (3.6), personne n'a de problème de corruption de données en 2.6.21.2 ?
 
Car chez moi, pas de souci en 2.6.21.1, en revanche, le boot via la version actualisée .2 est plus délicat (cad qu'il me donne des reiser.fsck 1 fois sur 2 pratiquement).
 
nb : j'ai checké mes partitions via un liveCD en 2.6.20, et tout est ok.

Moi depuis la 2.6.20 j'ai toujours grub qui met 3 plombes à lancer le noyau ... mais j'ai la flemme de faire un bug report

 
Pas sûr que ça aide, mais il y a une page qui parle d'un problème de possible corruption
avec libata et certaines distros qui ont modifiées la commande shutdown.
Du coup la commande qui permet le "flush" du cache disque n'est pas executée   :
 
http://linux-ata.org/shutdown.html

Merci loop0, je regarde les versions de mes scripts d'init et je vais upgrader en ~arch mes baselayout et udev.