Ton kernel doit avoir e base tout les drivers pour démarrer le rootfs. Ce n’est que plus tard qu’il peut utiliser des modules (via modprobe par ex) pour les périphériques non critiques au boot , comme si par exemple tu branches une webcam ou une souris usb.
I llui faut aussi “en dur” de quoi gérer le système de fichier sur lequel est installé ton rootfs.
Lequel as tu utilisé sur ta carte SD ? je te conseille un ext3, voire 2.
Aprés son boot, le kernel commence par monter cette partition (en ro). Est ce que tu vois cette étape sur la console ? tu peux rajouter l’argument rootfstype=ext3 par ex.
et ensuite; il lance init.
J’ai peur de ne pas pouvoir apporter une grande aide concernant le “BUG at net/netfilter/nf_conntrack_helper.c:187”. Je ne connais pas assez les entrailles du noyau. Si je connais plutôt bien netfilter et iptables, c’est surtout en tant qu’utilisateur.
Voici quelques infos néanmoins, en supposant que la version du noyau est 2.6.34(.x) comme cela figure dans certains messages.
La ligne 187 du fichier nf_conntrack_helper.c fait partie de la fonction nf_conntrack_helper_register(), où elle effectue une vérification “sanitaire” qui ne devrait jamais échouer. Cette fonction est appelée par les “assistants” (“helpers”) de suivi de connexion/NAT de divers protocoles applicatifs complexes, à savoir :
net/ipv4/netfilter/nf_nat_snmp_basic.c
net/netfilter/nf_conntrack_amanda.c
net/netfilter/nf_conntrack_tftp.c
net/netfilter/nf_conntrack_ftp.c
net/netfilter/nf_conntrack_netbios_ns.c
net/netfilter/nf_conntrack_sip.c
net/netfilter/nf_conntrack_h323_main.c
net/netfilter/nf_conntrack_sane.c
net/netfilter/nf_conntrack_pptp.c
net/netfilter/nf_conntrack_irc.c
C’est peut-être l’initialisation de l’un d’eux qui déclenche le BUG en passant une valeur hors limite à la fonction. Désactiver ceux qui ne sont pas strictement nécessaires dans les options de configuration du noyau pourrait éviter sa survenue. Mais c’est quand même surprenant, je pencherais plutôt pour un problème à la compilation.
EDIT: le seul helper qui semble initialiser explicitement le membre de structure expect_class_max testé à la ligne 187 est nf_conntrack_sip (protocole SIP pour la VoIP). La valeur d’initialisation SIP_EXPECT_MAX est définie implicitement à partir du dernier membre d’une enum dans include/linux/netfilter/nf_conntrack_sip.h, c’est donc potentiellement un bon suspect si d’aventure les valeurs des membres de l’enum affectées à la compilation ne suivent pas le schéma normal (0, 1, 2…)
Merci Pascal pour l’analyse. Je me pencherai sur la recompilation du noyau plus tard. J’essayerai différentes options de compilation ou de cross toolchain pour voir.
Mais là si je n’arrive même pas à monter le rootfs alors c’est mal parti pour la suite.
La première partition sur la microSD est de type b (ex: vue dans fdisk). Je l’ai formatée avec mkfs.msdos.
La seconde partition est ext2, formatée avec mkfs.ext2.
J’ai copié sur la première partition uImage et flashé la NAND suivant les instructions sur le site Amlogic. le device charge le kernel directement à partir de la NAND.
La seconde partition contient le rootfs compilé. A la racine, il y a les répertoires /bin /dev /etc /home /proc /root /lib /sbin /sys /tmp /usr /var et un lien symbolique vers /sbin/init et un second lien, linuxrc vers /bin/busybox.
J’ai aussi essayé avec un rootfs que j’ai compilé à partir de sources du constructeur.
enfin, j’ai essayé la procédure décrite dans
openlinux.amlogic.com/wiki/index … 726M_Howto
Je l’ai flashé sur la NAND en suivant la procédure
openlinux.amlogic.com/wiki/index … 726M_Howto
Mais dans tous les cas j’ai le message d’erreur
VFS: Cannot open root device “cardblksd2” or unknown-block(253,2), si j’essaye de charger à partir de microSD.
ou
VFS: Cannot open root device “mtdblock2” or unknown-block(31,2) si je flash le rootfs.img sur la NAND.
Il y a une option dans la config du noyau permettant d’obtenir un deug très bavard (verbose) ?
Peut être qu’il en dira plus sur cette erreur…
A un moment tu avais eu un message “Attempted to kill init”. Cela signifie que le processus init avait été exécuté, et donc qu’un racine (laquelle ?) avait été montée.
vérifie que dans ta compil de kernel, tu as bien mis en dur (pas en module) le driver pour le chipset et pour le système de fichier ext2.
Les gentooiste ont bien résumé la situation:
[quote]Analysis
The panic informs you that the Linux kernel is unable to either
detect the controller for your hard disk (a likely candidate if the message says unknown-block(0,0))
detect your partition because it doesn't have support for your partition types (less likely)
mount your partition because it doesn't know how to access the file system (a likely candidate if the message gives a non-zero figure in the first number set, such as unknown-block(2,0))
detect your partition because you passed the wrong device in your boot loader configuration
Resolution
Boot with your old kernel, or with the LiveCD and open the kernel configuration
root # make menuconfig
Ensure that your controller chipset is configured in the Linux kernel (and in-kernel, not as a module)
Ensure that the file systems you use (such as Ext2, Ext3, Ext4, ReiserFS ...) are configured in the Linux kernel (and in-kernel, not as a module) [/quote]
L’autre possibilité est dans la config de uboot.
L’analyse des exemples donnés par amlogic montre qu’ils recommende l’option init=/init
As tu essayé de booter sur un rootfs via NFS ?
encore une dernière idée: si j’ai bien compris, tu bootes ton kernel depuis la NAND. Essaie de ne mettre qu’une seule partition sur la SD en ext2 avec le rootfs.
La config de uboot peut étre parfois chronophage … Mais heureusement , on ne la fait qu’une fois.
Merci pour ces bonnes idées. Je ferai plusieurs essais et vous dirai quoi.
La compilation des noyaux linux avec un pentium M met un certain temps… si je dois en faire plusieurs pour remonter la route jusqu’au moment ou j’ai eu le message “Attempted to kill init!” alors mon PC deviendra d’ici là une antiquité. Je refais une compile qui intègre en dur un max de drivers nécessaires.
Dommage, j’avais gardé jusqu’à hier, sur mon disque dur l’ensemble des noyaux et rootfs que j’ai compilés. Cela me permettait d’avoir un minimum de traçabilité sur ce que j’ai fait.
Le problème est que le disque dur de 40GO a saturé. J’ai donc été obligé de faire le ménage. la commande df donnait 0 octet disponible. même squid3 ne pouvait pas fonctionner et je n’avais donc plus d’Internet.
Enfin, j’ai maintenant plus de 6 milliards d’octets de dispo sur le disque dur.
[quote]Attempted to kill init![/quote]c’est un message de boot, pas de compil
dans ton post du 06 janvier
Certes, mais il peut être lié à une configuration particulière du noyau à la compilation, qui a tout ce qu’il faut pour monter une racine.
Piratebab. Je me suis mal exprimé.
C’est bien entendu évident que “[ 3.805000] Kernel panic - not syncing: Attempted to kill init!” est un message de boot.
D’une part, j’ai compilé plusieurs versions de sources et avec différents toolchain. D’autre part, je n’ai pas gardé trace. Donc, je ne sais pas quelles sont toutes les combinaisons (kernel,toolchain) que j’ai faites.
Alors, si je dois faire autant de recompilations de noyaux que de combinaisons possibles ça prendra beaucoup de temps.
L’une de ces combinaisons à pu aller plus loin que les autres et a généré le message d’erreur en question.
J’ai retrouvé le source du kernel que j’ai utilisé, mais je n’ai pas le “.config” contenant la configuration qui va bien. Par contre, je ne sais pas quel rootfs j’avais utilisé. Je vais essayer d’avancer…
Essaie le boot sur nfs, tu gagneras du temps (pas de flash de la SD)
J’ai essayé mais je n’ai pas réussi. Alors j’avais remis cela à une autre fois.
Je n’ai pas gardé trace du message d’erreur précis. En gros il ne trouvait pas les infos sur nfs.
La commande uboot est la suivante, il est possible qu’elle soit pas bonne.
set bootargs root=/dev/nfs nfsroot=192.168.1.2:/home/nfs rw noinitrd init=/init ip=192.168.1.5:255.255.255.0:target:eth0:off console=ttyS0,115200,mac=xx:xx:xx:xx:xx:xx.
saveenv
J’ai mis la mac adresse du serveur ou est partagé le répertoire nfs. L’adrersse ip de ce serveur est
192.168.1.2.
Coté serveur, netstat renvoie :
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat User Inode PID/Program name
tcp 0 0 *:54200 : LISTEN root 6092 2221/rpc.mountd
tcp 0 0 *:55324 : LISTEN statd 3495 1034/rpc.statd
tcp 0 0 *:nfs : LISTEN root 5999 -
tcp 0 0 *:34983 : LISTEN root 6019 -
Le firewall laisse tout passer sur le réseau 192.168.1.0/24.
showmount renvoie Hosts on serveur:
192.168.1.5
Je n’ai pas chercher plus loin pour m’assurer que tout est correct. J’ai opté pour la solution de la microSD pour avancer.
S’il y a assez de place en mémoire flash NAND, tu pourrais peut-être essayer d’inclure un rootfs minimal sous forme d’initramfs directement dans le noyau, qui lancerait un shell et te permettrait de vérifier si la carte SD est accessible et sous quelle forme.
EDIT : En relisant les messages du noyau, j’ai le sentiment que les partitions de la carte SD sont bien reconnues, mais c’est lors du montage de ce qu’il y a sur celle désignée comme racine que ça coince. Donc soit le système de fichiers ext2 sur cette partition a un souci, soit le noyau n’a pas ce qu’il faut compilé en dur pour le gérer (CONFIG_EXT2_FS=y).
Je suis revenu sur la config qui donne le message "Kernel panic - not syncing: Attempted to kill init!"
Vous trouverez en pièce jointe le fichier Text_File.txt correspondant au debug du boot.
Dans cette version, on ne vois pas la micrSD. Le boot s’arrête plustôt.
si non, la commande grep “CONFIG_EXT2_FS*” .config, donne :
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
J’ai décoché netfilter qui génère beaucoup d’erreurs et recompilé le noyau.
le message “Kernel panic - not syncing: Attempted to kill init!” ne s’affiche plus.
Celui qui s’affiche est "[ 3.441000] cardblksd: cardblksd1
[ 3.460000] VFS: Cannot open root device “cardblksd2” or unknown-block(254,2)"
Ci-joint le fichier Text_File.txt2 correspondant au debug du boot.
Text_File2.txt (13.4 KB)
Text_File.txt (20.4 KB)
Apparemment ce message est juste une conséquence du BUG causé par netfilter.
En tout cas avec la trace complète on voit que la fonction appelante est nf_conntrack_sip_init, ce qui va dans le sens de mon hypothèse incriminant le helper SIP. En désactivant juste CONFIG_NF_CONNTRACK_SIP (et CONFIG_NF_NAT_SIP qui en dépend) plutôt que tout netfilter, cela ne devrait plus se produire.
Dans l’autre fichier on voit que le montage de la racine échoue parce que la partition spécifiée cardblksd2 n’existe pas, il n’y a qu’une partition cardblksd1 sur la carte. Dans une autre trace que tu as fournie il y avait bien une seconde partition et les numéros majeur et mineur semblaient correspondre 0xfd02=(253,2).
Après avoir fait quelques tests, j’en arrive à la conclusion que si le problème était du côté du système de fichiers ext2, le message d’erreur serait différent : “no filesystem could mount root” et non “cannot open root device”. Le message d’erreur veut bien dire que le périphérique bloc désigné comme racine n’a pas pu être ouvert, comme s’il n’existait pas. Mais sur la trace de la page 2 on voit bien qu’il existe puisque le noyau l’affiche avec sa taille :
[ 3.541000] cardblksd: cardblksd1 cardblksd2
[ 3.600000] VFS: Cannot open root device "cardblksd2" or unknown-block(253,2)
[ 3.602000] Please append a correct "root=" boot option; here are the available partitions:
[...]
[ 3.650000] fd00 3813376 cardblksd driver: cardblk
[ 3.655000] fd01 1054000 cardblksd1
[ 3.659000] fd02 2756985 cardblksd2
J’en perds mon latin. As-tu essayé avec une racine directement sur /dev/cardblksd sans table de partition ?
Le message d’erreur a du être généré par une fonction init de quelque chose dans netfilter qui a du échouer. On voit bien que le boot n’allait pas plus loin.
C’est normal que l’on voit qu’une seule partition. J’ai créé et formaté la microSD en une seule partition. J’ai oublié de mettre à jour la variable “bootargs” pour uboot, le rootfs est sur la première partition. La partition de tybe b ne servira que pour flasher un uImage sur la NAND, pour l’instant je fais les essais avec tftpboot.
Je mets à jour le fichier debug avec la version du kernel compilé avec Netfilter et sans les CONFIG_NF_CONNTRACK_SIP et CONFIG_NF_NAT_SIP.
Depuis le début Je formate la microSD avec un lecteur qui se branche sur un port USB. Je me demande si ce n’est pas ce lecteur qui ne formate pas correctement (bug)??.
Text_File3.txt (14.7 KB)
essaie de relire la carte dans un autre lecteur.
Ce boot à l’air plus propre que le précédent, je ne suis pas encore arrivé au bout, mais je vois:
Si tu as un port usb, tu peux essayé de mettre le rootfs sur un stick mémoire (uboot à modifier évidement)
Autre idée, essaie
J’ai essayé avec root=fe01. ça donne la même erreur
[ 2.522000] VFS: Cannot open root device “fe01” or unknown-blockb[/b]
[ 2.528000] Please append a correct “root=” boot option; here are the available partitions:
[ 2.537000] 1f00 8192 mtdblock0 (driver?)
[ 2.541000] 1f01 8192 mtdblock1 (driver?)
[ 2.546000] 1f02 8192 mtdblock2 (driver?)
[ 2.551000] 1f03 307200 mtdblock3 (driver?)
[ 2.556000] 1f04 16384 mtdblock4 (driver?)
[ 2.561000] 1f05 167936 mtdblock5 (driver?)
[ 2.566000] 1f06 8 mtdblock6 (driver?)
[ 2.571000] 1f07 2048 mtdblock7 (driver?)
[ 2.576000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,1)
Je ferai les autres essais ce soir.
Résultat prévisible puisqu’on voyait bien que le nom de périphérique était bien converti en numéros majeur et mineur (254,1) = 0xfe01.
En tout cas tu m’as donné confirmation pour nf_conntrack_sip. Il y a un souci avec le traitement des valeurs de l’enum. Du coup, je me demande s’il n’y aurait pas un bug de compilation (optimisation trop poussée, archi ARM ?) qui pourrait affecter le fonctionnement du noyau à d’autres endroits de façon plus subtile, et pourquoi pas, causer le problème de la racine.
Je vois que tu utilises une version de GCC (4.7) relativement récente par rapport à la version du noyau (2.6.34), ce qui est connu pour causer des problèmes parfois.
Une incompatibilité de la carte avec le device n’est pas à exclure. Mais il me semble que tu as déja réussi à booter le kernel sur la SD, ce qui invaliderait cette hypothèse.
En farfouillant sur le net, j’ai trouvé un log de boot qui ressemble fortement au tiens, mais pour lequel le rootfs démarre. La différence que j’ai trouvé c’est que la partition est en ext3 (et aussi que l’horloge est correctement initialisée, ce qui ne semblepas le cas chez toi si j’ai bien lu)
wiki.opennet.ru/?title=Zenithink_C71&action=edit
[quote]aml_rtc aml_rtc: setting system clock to 2012-04-07 20:46:11 UTC (1333831571)
[ 3.081000] wait …
[ 3.121000]
[ 3.121000] SD/MMC initialization started…
[ 3.641000] Actual delay time in sd_voltage_validation() = 30 ms
[ 3.706000] set sd_mmc config_reg->cmd_clk_divide 1, CLK 45M
[ 3.707000] sd_mmc_init() is completed successfully!
[ 3.709000] This SDHC card is working in Wide Bus and high speed mode!
[ 3.709000]
[ 3.713000] cardblksd: cardblksd1 cardblksd2
[ 5.000000] Speaker on
[ 6.091000] Waiting 10sec before mounting root device…
[ 98.305000] kjournald starting. Commit interval 5 seconds
[ 99.261000] EXT3-fs (cardblksd2): using internal journal
[ 99.263000] EXT3-fs (cardblksd2): recovery complete
[ 99.269000] EXT3-fs (cardblksd2): mounted filesystem with writeback data mode
[ 99.271000] VFS: Mounted root (ext3 filesystem) on device 253:2.
[ 99.275000] devtmpfs: mounted[/quote]