Forum Linux.noyau [RT Linux] sbin/init error 8 (exists but couldn't execute it)

Posté par  . Licence CC By‑SA.
Étiquettes :
0
1
fév.
2015

Bonjour à tous,

J'ai comme projet d'« installer » (ou plus exactement de booter) un noyau Linux temps-réel. Pour ce faire, j'ai téléchargé le noyau Linux 3.14.29 et je l'ai patché avec RT Linux 3.14.29-rt26. Puis j'ai configuré le noyau ainsi patché pour ensuite le compiler, et générer son initrd… Jusque-là, tout semble bien se passer : aucune erreur ne s'affiche.

Mais (car oui, il y a un « mais », sinon ce topic n'aurait pas lieu d'être☺ ), après avoir configuré à la main grub.cfg - celui-ci ne s'étant pas màj automatiquement suite à initrd, allez savoir pourquoi… - , je lance le boot RT Linux et là, l'erreur « sbin/init error 8 (exists but couldn't execute it) » s'affiche. D'après Google, l'erreur n°8 indique que le fichier init est corrompu (mauvais format de fichier).

Alors, je décide de réinstaller ma distrib', openSUZE (distrib' sous laquelle j'ai compilé, configuré, etc. RT Linux), et je recommence tout de A à Z : l'erreur s'affiche encore. J'espérais que le processus init se serait regénéré suite à cette réinstallation, mais il n'en n'est rien.

Le plus étonnant, c'est que le boot de openSUZE marche parfaitement : pas d'erreur de corruption du fichier init.

Je ne sais pas du tout quoi faire. Voici deux fichiers qui, peut-être, pourraient avoir une certaine utilité… (n'hésitez pas à me demander d'en envoyer d'autres si c'est nécessaire : je le ferai volontiers ! ☺ ) :

1- Fichier .config du noyau patché : http://textup.fr/117717qW
2- Fichier /boot/grub2/grub.cfg (configuration de GRUB2) : http://textup.fr/117719l2

En vous remerciant d'avance ☺,
Bonne journée

  • # au hazard, une histoire de compression ?

    Posté par  . Évalué à 3. Dernière modification le 01 février 2015 à 17:05.

    deja ca ne va pas marcher ton OS est sur du BTRFS, mais ton noyau ne l'a pas dans ses pilotes

    en effet, dans ton GRUB : 

    set btrfs_relative_path="y"
export btrfs_relative_path

    mais dans ton CONFIG

    # CONFIG_BTRFS_FS is not set

    Ensuite quand on compare les lignes du GRUB de Suse

    menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-c5e1f2e1-9b45-4d23-b30d-56c17e4162f9' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod btrfs
        set root='hd0,msdos3'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3'  c5e1f2e1-9b45-4d23-b30d-56c17e4162f9
        else
          search --no-floppy --fs-uuid --set=root c5e1f2e1-9b45-4d23-b30d-56c17e4162f9
        fi
        echo    'Chargement de Linux 3.16.6-2-desktop…'
        linux   /boot/vmlinuz-3.16.6-2-desktop root=UUID=c5e1f2e1-9b45-4d23-b30d-56c17e4162f9  ${extra_cmdline}  resume=/dev/disk/by-uuid/cee2d162-3e04-4088-b9bc-2f6454ca9d9c splash=silent quiet showopts
        echo    'Chargement du disque mémoire initial…'
        initrd  /boot/initrd-3.16.6-2-desktop
}

    à tes lignes à toi,

    ### BEGIN /etc/grub.d/10_linux ###
menuentry 'RTLinux' {
        set root='hd0,msdos3'
        linux /boot/vmlinuz-3.14.29-rt26 root=UUID=c5e1f2e1-9b45-4d23-b30d-56c17e4162f9 ro
        initrd /boot/initrd-3.14.29-rt26
}

    on voit quand meme qu'il manque quelques lignes, entre autre les insmod qui vont charger les pilotes de filesystem avant d'aller plus loin.

    donc dans ton cas, ajoute le support de BTRFS dans le noyau, et ajoute les lignes insmod dans grub
    ca ira mieux.

    note : pas besoin de reinstaller la distrib, fait la juste booter sur l'entrer suse pour retourner sur le noyau d'origine.

    • [^] # Re: au hazard, une histoire de compression ?

      Posté par  . Évalué à 1.

      Bonjour,

      Merci d'avoir pris le temps de me répondre.
      J'ai supprimé la menuentry 'RTLinux'. En effet, GRUB2 avait bel et bien créé la bonne entrée, elle est juste un peu cachée, et je ne l'ai pas remarquée (c'est un sous-menu en fait)…
      Du coup, les problèmes des insmod est réglé.

      J'ai rajouté le support BTRFS dans le .config, et j'ai aussi activé BINFMPT_AOUT.

      Mais je rencontre toujours le même problème. Du coup, je vais remplacer le .config du noyau patché par celui de ma distrib', et appliquer dessus un ou deux changements nécessaires au support de RT Linux.

      Je mettrai à jour ce post ☺.

  • # Problème résolu - Solution

    Posté par  . Évalué à 2.

    Edit important :

    En fait, ce bug était tout simplement dû à la commande bash make i386-config, puisque cette dernière a configuré le noyau pour être un kernel 34 bits.

    Or, ayant lancé un bash file sur le fichier systemd, j'ai pu remarquer que init était un lanceur 64bits (init étant un lien symbolique vers systemd).

    Donc le kernel ne pouvait naturellement pas utiliser init (d'où le message d'erreur n°8).

    Au final j'ai utilisé le .config de mon openSUSE, puis j'ai fait un make menuconfig pour activer l'option CONFIG_PREEMPT_FULL (Processor type and features —> Preemption Model () —> Fully Preemptible Kernel (RT)).

    J'ai aussi suivi les étapes suivantes (étapes qui m'ont été données sur la mailing-list du projet RT Linux - linux-rt-users@vger.kernel.org) :

    1. Download the RT patch, unpack and apply them
    2. Copy the distro config to .config in the kernel tree
    3. Type make menuconfig and select "Processor type and features —>"
    4. Goto "Preemption Model () —>"
    5. Select "Fully Preemptible Kernel (RT)"
    6. Save and quit
    7. Type make; make modules_install install (attention, il n'y a aucune faute de frappe : c'est bien « make modules_install install »)
    8. Reboot and select the newly provided grub entry

    • [^] # Re: Problème résolu - Solution

      Posté par  . Évalué à 2.

      ben si tu utilises un system 64bits, pourquoi ne pas simplement faire un make x86_64-config poour avoir un noyau en 64bits ?

    • [^] # Re: Problème résolu - Solution

      Posté par  (site web personnel) . Évalué à 4.

      En fait, ce bug était tout simplement dû à la commande bash make i386-config, puisque cette dernière a configuré le noyau pour être un kernel 34 bits.

      Si make i386-config, à généré un noyau 34 bits. je confirme, c'est un bug :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.