Forum Linux.noyau Il ne boote pas mon noyau

Posté par  (site web personnel) .
Étiquettes :
2
24
mai
2011

Bonjour à tous,

après avoir obtenu du nouveau matériel, la dernière mise à jour de mon système a cassé mon Linux, et je viens crier à l'aide!

Si vous avez un matériel analogue au mien, parlez-moi de votre setup! Pour les plus charitables d'entre vous j'ai quelques questions subsidaires à la fin.

Matériel

Carte-mère: ASUS M4A88TD-M/USB-3, chipset AMD880G/SB850
Prosso: AMD Phenom II
Vidéotron: Radeon HD5450, CEDAR

Clavier: PS/2, designed for Windows 95
Souris: USB, Microsoft ;)

Une façade multimédia avec un port USB et des lecteurs de cartes SD branchés sur les carte-mère, via USB.

Logiciel

Ma viellissante Debian Lenny marchait très bien sur la bête, jusqu'au jour où Squeeze est sortie. À l'installation de Squeeze je rencontre le problème suivant: impossible pour le noyau d'installation de trouver le lecteur de CD-ROM contenant le CD d'installation! L'installation depuis un support USB se fait sans problème.

Problème

Le noyau Linux (2.32, 2.38 et 2.39) ne démarre pas certainement sur cette machine: il me faut en général trois ou quatre tentatives pour démarrer. Lorsque la machine est boottée, elle est stable et fonctionne sans problèmes.

Diagnostics

  1. La machine démarre avec les paramètres nolapic et noacpi.
  2. Désactiver les composants dans le BIOS ne m'a pas permis d'isoler le composant fautif.
  3. La seule recurrent pattern dans l'échec du boot semble être la date de plantage: environ 2.81 secondes après le démarrage.
  4. La machine démarre et fonctionne correctement avec FreeBSD 8.1.

Correctement signifie que même certaines caractéristiques très spécifiques à la carte-mère sont prises en charge et fonctionnent. Le support de la carte vidéo reste limité. Le seul petit couic au démarrage est le message:

ACPI Error: [PCI0] Namespace lookup failure, AE_NOT_FOUND (20101013/dswload-772)
ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20101013/psloop-326)
ACPI Error: Method parse/execution failed [\] (Node 0xffffffff8090e660), AE_NOT_FOUND (20101013/psparse-633)
acpi0: Power Button (fixed)
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of fec10000, 20 (3) failed
acpi0: reservation of fed40000, 5000 (3) failed
acpi0: reservation of fed80000, 1000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed

Questions

Si vous avez des conseils ou des expériences à partager avec moi, soyez les bienvenus.

J'ai besoin d'un système Linux pour faire marcher la dernière version Handbrake. qui n'est pas portée sous FreeBSD. Mes alternatives sont:

  1. Installer Debian/kFreeBSD.
  2. Installer une distribution source-based qui me permettrait d'utiliser un noyau obsolète avec des logiciels modernes, ce qui me semble hasardeux à cause du passage libc5/libc6, je suis particulèrement interssé par vos avis sur cette question.
  3. Utiliser un logiciel analogue à Handbrake qui fonctionne sous FreeBSD.

  • # Comportements hasardeux du contrôleur disque

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

    Ces derniers mois, j'ai rencontré plusieurs problèmes avec le kernel 2.6.38. Les machines impactés sont :
    - un portable sous Ubuntu 10.10 (ce n'est pas le mien, je fais juste du support dessus)
    - plusieurs PC desktop sous Debian Testing (les problèmes sont intervenus plusieurs mises à jours après le passage de Squeeze à Wheezy)

    Les symptômes sont que la machine ne boot plus. En supprimant le paramètre noyau "quiet", on voit nettement que le kernel a du mal à communiquer avec tout ce qui est PATA/SATA (disque dur, CDROM, ...).

    J'ai pas mal cherché sur le net, et il en ressort que la cause peut-être un problème de syncho entre contrôleur disque et périphériques. Aussi différents paramètres noyaux peuvent être testés:
    libata.force=noncq
    libata.force=noncq,1.5Gbps
    libata.force=noncq,3.0Gbps
    libata.noacpi

    Sur une machine particulièrement récalcitrante, j'ai fini par tester ces paramètres-là:
    acpi=noirq
    acpi=off

    Evidement, cette dernière combinaison n'est pas sans effet indésirable, vu que la machine ne peut plus faire de "power off", et doit être arrêtée manuellement. Par contre, cela a définitivement résolu le problème de la machine Ubuntu.

    Remarque : Je ne sais pas si "noacpi" fonctionne encore. Il me semble que c'est "acpi=off" qu'il faut utiliser.

    • [^] # Re: Comportements hasardeux du contrôleur disque

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

      Merci beaucoup pour ces conseils utiles … malheureusement ils se sont avérés inefficaces.

      Du coup, si personnes ici n'a de meilleure idée, je pense à passer à Debian/kFreeBSD ou à FreeBSD/Gentoo pour pouvoir utiliser Handbrake avec les six prossos de ma machine — ce qui est le but de mon achat.

  • # bios ?

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

    J'avais des problèmes assez similaire sur une machine utilisant bon nombre de même facture (chipset, cpu, gpu). Finalement, c'est une mise à jour du firmware de la carte mère qui est venue à bout des démarrages hasardeux. Peut-être faut-il regardez de ce côté ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: bios ?

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

      Finalement, c'est une mise à jour du firmware de la carte mère qui est venue à bout des démarrages hasardeux.

      Un de mes premiers réflexes a effectivement été de mettre à jour le firmware de ma carte-mère … c'est malheureusement resté sans effet!

  • # DVD-ROM

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

    Du nouveau: dans ma nomenclature j'avais oublie d'inclure un innocent DVD-ROM Phillips SPD2411P. Je l'ai deconnecte, juste pour voir, et c'est apparemment lui le fautif.

    Ce DVD-ROM est connecte sur la carte mere a un port IDE dont le controleur est un VIA VT6415. Si a la lumiere de ces nouvelles informations vous avez une idee ... elle est la bienvenue!

    • [^] # Re: DVD-ROM

      Posté par  . Évalué à 1.

      Sur un vieux système (AMD Athlon à 1200 MHz), j'ai justement eu des ennuis avec un graveur DVD Phillips et un VIA686B. Quand il était en esclave du 2ème contrôleur IDE, il:
      -fonctionnait avec DMA sous Slackware 11.0/Linux 2.4.33
      -ne fonctionnait pas avec DMA sous Slackware 11.0/Linux 2.6.17.13
      -fonctionnait uniquement pour graver des CD (mais pas pour les lire, et j'avais pas testé les DVD) sous Zenwalk et Linux ~2.6.17
      -à l'époque de Linux 2.6.20-2.6.25, ne lisait les CD que sous Slackware, Ubuntu et Debian (sans doute libata vs. vieux IDE)
      Quand j'ai arrêté de mettre des lecteurs optiques en position du /dev/hdd, ça s'est mis à mieux marcher (et je crois avoir lu un jour que mettre un lecteur optique en /dev/hdd constituait un violation de la norme ATAPI).
      Enfin, quand j'ai mis à jour le firmware du lecteur DVD (un grand merci au passage pour Phillips qui m'a fait installer W2K juste pour cette mise à jour…) ça s'est encore amélioré, et j'ai plus remarqué de problème après (mais j'ai aussi quasiment arrêté de m'en servir, aussi).

  • # libc5/libc6, vraiment ?

    Posté par  . Évalué à 1.

    ce qui me semble hasardeux à cause du passage libc5/libc6

    Parce que bon, libc5/libc6 ça date quand même de l'avant-Linux 2.4.
    Sinon, le vrai problème pour utiliser un noyau vraiment plus ancien que la distribution c'est udev. Sous les Slackware récentes, glibc est compilée pour le noyau 2.6.18 et udev demande un noyau 2.6.27, mais plus récent si on utilise les règles par défaut. Donc si ça ne te dérange pas de ne pas utiliser udev et d'utiliser rc.modules à la place, tu peux sans problème utiliser Slackware 13.37 avec le noyau 2.6.27.31 issu de Slackware 12.2 ;).
    Sinon, si c'est le support qui te gêne pour rester sur Lenny, tu peux toujours passer à Slackware 12.2 (noyau 2.6.27.31) ou CentOS 5/SL5 (noyau 2.6.18). Avec Slackware, les mises à jour pour les paquets sont fournies «tant que c'est facile de faire le paquet», ce qui fait que les versions >= 8.1 ne tombent jamais en obsolescence brutale (pour le moment, dans Slackware 12.2, Firefox n'est plus mis à jour mais SeaMonkey l'est encore).

  • # libc5/libc6, vraiment ?

    Posté par  . Évalué à 1.

    ce qui me semble hasardeux à cause du passage libc5/libc6

    Parce que bon, libc5/libc6 ça date quand même de l'avant-Linux 2.4.
    Sinon, le vrai problème pour utiliser un noyau vraiment plus ancien que la distribution c'est udev. Sous les Slackware récentes, glibc est compilée pour le noyau 2.6.18 et udev demande un noyau 2.6.27, mais plus récent si on utilise les règles par défaut. Donc si ça ne te dérange pas de ne pas utiliser udev et d'utiliser rc.modules à la place, tu peux sans problème utiliser Slackware 13.37 avec le noyau 2.6.27.31 issu de Slackware 12.2 ;).
    Sinon, si c'est le support qui te gêne pour rester sur Lenny, tu peux toujours passer à Slackware 12.2 (noyau 2.6.27.31) ou CentOS 5/SL5 (noyau 2.6.18). Avec Slackware, les mises à jour pour les paquets sont fournies «tant que c'est facile de faire le paquet», ce qui fait que les versions à partir de la 8.1 (2002) ne tombent jamais en obsolescence brutale (pour le moment, dans Slackware 12.2, Firefox n'est plus mis à jour mais SeaMonkey l'est encore).

    • [^] # Re: libc5/libc6, vraiment ?

      Posté par  . Évalué à 1.

      Et merde, double post, à cause du serveur qui n'a pas aimé mon >= qui tombait au début de la ligne et qui a envoyé mon commentaire en m'affichant une erreur 500.

Suivre le flux des commentaires

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