Ca me met ca en 2ème ligne, juste après un message de l’ACPI (dont un des composants est en conflit avec un autre j’ai pas fouillé vu que ca ne pose pas de problème avec l’initrd)
Comment ça en deuxième ligne ? Le noyau n’écrit que deux lignes en tout avant de s’arrêter ?
Oui
Euh, j’y pense, tu n’aurais pas “quiet” dans les options de démarrage du noyau ? Si oui il faut l’enlever pour afficher tous les messages.
de fait!
Sans quiet j’ai pas mal de lignes (acpi, usb,…) puis :
VFS: cannot open root device on “UUID=(…)” or unknown-block (0,0)
please apend a correct “root=” boot option
Rien concernant le contrôleur SATA et le disque (ahci, ata, sd…) ?
ya un moyen de récupérer les messages sans avoir à redémarrer et lire betement? 
A moins de booter sur une console série capable d’enregistrer, j’ai peur que non.
Méthode artisanale : prendre une photo de chaque page en remontant, ça permet de regarder plus confortablement. Mais bon, je pense que les messages relatifs aux contrôleurs disques sont assez visibles.
je peux pas remonter.
Sinon j’ai filmé mais on voit pas grand chose ceux qui semble demarrer: ACPI ahci USB ALSA surement d’autre mais je vois pas…
Zut, c’est vrai qu’après le kernel panic on ne peut rien faire.
Dans ce cas tu peux booter le même noyau avec l’initrd et l’option de démarrage “break=top” pour s’interrompre et ouvrir un shell au début du script init de l’initramfs. Là tu pourras remonter. Si tu ne vois rien, quitte le shell et le démarrage se poursuivra. Ensuite tu pourras regarder dans la liste des premiers modules chargés (en partant du bas) pour essayer de trouver ce qui manquait.
Note : chez moi, après le message “panic”, ça affiche la liste des volumes détectés. Si ça n’affiche rien chez toi, c’est qu’il manque quelque chose pour détecter le disque.
Il me liste les disques apres le messages d’erreur (sda1 etc juste avant le kernel panic, apres le “please append…”
Donc le disque et ses partitions sont détectés.
J’y pense, le noyau est-il capable seul d’identifier un volume par son UUID ? Qu’est-ce que ça donne si tu remplaces UUID= par le nom de la partition racine /dev/sdaX dans les options de démarrage ?
Bingo! Ca roule… (Quand je pense à la bonne dizaine de compils à cause de ca 
)
Merci bcp PascalHambourg!! 
Bonne soirée
Ah, tous les deux on n’a pas été très bons sur cette affaire. Je n’avais pas fait attention au “root=UUID” glissé dans un de tes messages, et ce n’est qu’après avoir acquis la certitude que les partitions étaient bien détectées que j’ai tout relu et fini par remarquer ce détail capital. J’ai aussi des noyaux sans initrd/initramfs, mais n’ayant jamais utilisé les UUID (encore un truc trop moderne pour moi, comme udev…) je ne savais pas que le noyau ne pouvait s’en servir pour identifier un système de fichiers. Si j’ai bien compris, c’est udev qui lit l’UUID et le label d’une partition et crée les liens symboliques dans /dev/disk/by-uuid/ et /dev/disk/by-label/ pointant vers le nom “canonique” de la partition.
Bref, pour identifier la racine par UUID ou label, il faut un initramfs ou initrd. Je ne sais pas si c’est un fait connu mais l’initramfs n’est pas forcément dans un fichier distinct du noyau, il peut être inclus directement dans l’image du noyau lors de la construction de celle-ci, cf. l’option de configuration INITRAMFS_SOURCE du noyau. Les distributions GNU/Linux binaires comme Debian utilisent un initramfs séparé car elles y mettent des modules du noyau, et c’est plus souple puisqu’on peut regénérer un initramfs séparé sans reconstruire l’image du noyau. En revanche si l’initramfs ne contient que des programmes userland, par exemple udev pour la détection des UUID et labels, alors il est possible de l’intégrer au noyau à la compilation pour pouvoir identifier la racine par son UUID ou son label.
J’aurais vraiment du y penser, l’erreur était claire… Enfin c’est comme ca qu’on apprend!
J’ai jamais compris l’interret de l’identification par UUID, c’était trop simple avant? j’ai regardé un peu sur internet, c’est peu convainquant pour l’utilisateur lambda que je suis.
Pour l’instant je me contante d’éditer le grub, j’essaierai de trouver une solution plus propre quand j’aurais le temps… Il me semblait avoir mis les module pour udev en dur non? Ca voudrait donc dire qu’il faut mettre l’iniframfs obligatoirement, intégré ou non?
C’était simple quand les disques avaient un nom de périphérique constant dépendant de leur position. En IDE, c’était généralement le cas puisque hda était le périphérique 0 (maître) sur le premier canal IDE et etc. Maintenant notamment avec le PATA/SATA, l’USB tout s’appelle sda, sdb… et avec hotplug selon l’ordre d’énumération du contrôleur, du port, du disque, l’ordre de branchement… les noms peuvent changer :
- on enlève ou ajoute un disque PATA/SATA/SCSI -> ça peut décaler les noms au prochain démarrage ;
- on insère des mémoires de masse USB -> le nom dépend de l’ordre d’insertion.
L’UUID ou le label sont au contraire propres à une partition, cela permet de l’identifier de façon permanente quel que soit son nom de périphérique et de la monter toujours au même point de montage.
Il n’y a pas de module pour udev. Udev est purement userland.
Pour spécifier la racine par son UUID ou son label dans l’option root=, oui, c’est ce que j’en ai conclu dans mon message précédent.
Je pense qu’il s’agit des options du kernel pour faire fonctionner udev correctement, notamment une version >= 145
cf: git.kernel.org/?p=linux/hotplug/ … 679c3ed27d
J’avais lu un peu vite ton post PascalHambourg, autant pour moi…
Oui c’était bien ca, je pensais (bêtement sans réfléchir) que udev était maintenant intégré dans le module hotplug.
Je m’étais rendu compte du changement de nom pour les périphériques usb quand je montais tout à la main sur un vieux pc, j’aurais bien aimé pouvoir affecter un periférique à un point de montage particulier, selon son UUID… C’est vrai que c’est intéressant, dommage d’être obligé de passer par un userland pour le démarrage!
Il n’y a pas plus de module hotplug que de module udev dans le noyau. “Hotplug” est une fonctionnalité du noyau qui peut être exploitée par des programmes userland comme hotplug anciennement et son remplaçant actuel udev.
Et ça ce n’est pas le pire. Imaginons par exemple que tu laisses une clé mémoire USB branchée lors du démarrage et que le pilote USB soit chargé avant le pilote SATA : c’est alors la clé USB qui devient inopportunément /dev/sda à la place du disque SATA interne !
J’avoue que j’avais fait l’amalgame entre le userland hotplug et le module HOTPLUG du noyau, et par extension udev… Décidément j’ai de grosses lacunes Je me pencherais sur udev, hal, dbus, etc… quand j’aurais le temps, c’est pas clair dans ma tête…
Merci en tout cas pour votre aide!