Forum Linux.debian/ubuntu Pire que kernel panic !!

Posté par  .
Étiquettes :
0
3
mar.
2006
Ne riez pas, la semaine est dure.
Et bonjour ;)

Dimanche j'ai souffert d'un joli kernel panic, résolu presque facilement en recréant les symlinks /vmlinuz et /initrd.img qui pointent vers les éléments du noyau dans /boot, ça se passait là :
http://linuxfr.org/forums/15/15167.html

Depuis j'ai complété mon lilo.conf (voir en bas) pour accéder à mon noyau en direct.
Mais ce matin, le boot sur le noyau 2.6.15 s'arretait après :
Bios checked .... loading linux et puis RIEN!

Qu'ai-je fais pour tout casser ? je ne sais pas exactement, mais hier, en tentant de prendre en compte mon modem interne, j'ai lancé un "updates-modules". je ne vois pas d'autres pistes.

Qu'ai-je fais pour casser encore plus ? Je boote sur le noyau de secours, 2.6.12 :
* je recrée les liens au cas ou... pas mieux.
* je désinstalle/réinstalle le noyau 2.6.15... il me dit de faire attention à /?/?/modules-je ne sais quoi qui existe déjà (désolé pour le manque de précision)... j'accepte tout de même et ... pire! Plus moyen de booter, ni 2.6.15, ni 2.6.12.

A priori, la mémoire n'est pas en cause (windows se charge... ça me fait une belle jambe), et là je teste la mémoire avec un memtest lancé depuis Knoppix : pas d'erreur en vu, mais le test n'est pas fini.

Mais je ne sais plus trop où chercher. Comment permettre la prise en compte d'un noyau ? peut-on modifier lilo sans être dans le système ? si besoin, comment créer une disquette ou un cd de rescue pour debian (sans etre dans le système, encore une fois) ?

Je cherche de mon côté mais si vous avez des idées pour me sortir de là, je les testerai avec plaisir.
Merci

Configuration :
Portable asus L3000D,
processeur AMD
debian testing

lilo.conf :
boot=/dev/hda
root=/dev/hda3

#install=/boot/boot.b
install=/boot/boot-bmp.b
bitmap=/usr/share/lilo/sarge.bmp
bmp-colors=1,,0,2,,0
bmp-table=120p,173p,1,15,17
bmp-timer=254p,432p,1,0,0

map=/boot/map
prompt
default= Linux
timeout= 70

image=/vmlinuz
label=Linux
initrd=/initrd.img
append="acpi=on"
vga=791

image=/boot/vmlinuz-2.6.15-1-k7
label=Linux-direct
initrd=/boot/initrd.img-2.6.15-1-k7
append="acpi=on"
vga=791


#au cas ou
image=/boot/vmlinuz-2.6.12-1-k7
label= LinuxOld-26.12
initrd=/boot/initrd.img-2.6.12-1-k7
append="acpi=on"
vga=791

other=/dev/hda2
label=XP
  • # au cas ou

    Posté par  . Évalué à 2.

    si j'etais dans cette situation, je tenterais de ne pas avoir acpi=on dans le loader.
    A brule pourpoint je prendrais une distrib livecd (knoppix par exemple)
    je genererais une disquette avec grub-install puis je rebooterais dessus.
    Ne pas oublier de modifier le bios pour mettre la disquette en premier.
    L'avantage de la disquette et de grub est que l'on peut modifier facilement les options du kernel au boot (appuie sur la touche e).
    Je souspsonne acpi car c'est un truc qui plante bien ces derniers temps avec les differents kernels
  • # quelques pistes

    Posté par  . Évalué à 3.

    je n ai pas la pretention de resoudre ces problèmes mais pour info,
    le message que tu as eu concernant les modules te disait que tu allais ecraser les anciens modules (dans /lib/modules/2.6.12) vu que tu recompilais un nouveau noyau mais pour la meme branche.Quand on fait ce genre de bidouillages,c est bien de se faire une petite copie 2.6.12.old des modules pour eviter le genre de surprises..
    deja tu peux editer et aller voir si tu n as pas changé qqchose á ce niveau la...
    sinon , tu peux en effet booter avec un live-cd et editer grub (ou lilo dans ton cas )mais après avoir remonté un de tes systemes de fichiers...
    quand á ton lilo, je ne suis pas dans ta tete mais pourquoi un initrd(vu que tu n as pas mentionné faire du raid,et que tes disques ne sont pas scsi), et d accord pour essayer sans l acpi avec la ligne passée á la postérite
    linux noacpi noapic nolapic acpi=off
    bonne chance
  • # Sauvé... par chroot

    Posté par  . Évalué à 2.

    Merci à vous deux, et merci à L'IRC et à y0m,

    Ce n'était pas un problème de acpi, ni un problème de lilo mais un problème de modules.
    En effet, j'ai changé de noyau (sans recompilé, en fait, ça viendra après) et j'ai gardé le vieux /lib/module/2.6.15... Je ne sais pas à quel niveau ça agit, mais ça ne marchait plus du tout.

    Alors, la solution, si quelqu'un d'autre passe par là (et pour moi) :
    booter sur un live-cd (en l'occurrence ubuntu live)
    En root :
    *Monter la partition hda3 qui contient mon système,
    *Changer la racine avec chroot,
    *Du coup, dans le terminal où on travaille, un "apt-get truc" agit sur le systeme du portable et non sur le systeme du liveCD (je ne connaissais pas).
    *Supprimer les noyaux, sauvegarder /lib/module/2.6.15-1-k7
    *Réinstaller un noyau
    *Mettre à jour lilo.conf
    *Mettre à jour lilo
    * ... Rebooter sur le disque... Etch's alive, alleluia.

    En d'autres termes, dans ubuntu :
    $ sudo -s
    # mkdir /mnt/hda3
    # mount /dev/hda3 /mnt/hda3/
    # mkdir /mnt/proc # ça je ne suis pas sur que ce soit important
    # mkdir /mnt/dev # c'est proposé comme ça
    # mount -t proc none /mnt/proc/ # dans le gentoo handbook
    # mount -o bind /dev /mnt/dev #
    # chroot /mnt/hda3/ /bin/bash # l'arme fatale :)

    Puis une fois en que la partition du disque est à nouveau la racine :
    export PS1="(chroot) $PS1" # c'est plus joli
    apt-get update
    apt-get remove linux-image-2.6.15-1-k7
    apt-get remove linux-image-2.6.12-1-k7
    mv 2.6.15-1-k7/ 2.6.15-1-k7-old
    apt-get install linux-image-2.6.15-1-k7
    ln -s /boot/vmlinuz-2.6.15-1-k7 vmlinuz
    ln -s /boot/initrd.img-2.6.15-1-k7 initrd.img
    nano etc/lilo.conf # faire ce qu'il faut
    lilo
    reboot

    @karmatrix
    Pourquoi initrd ? Très bonne question, surement parce qu'il était là. Je ne me suis jamais penché sur cet animal là.
  • # Utiliser grub ?

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

    Tout est dans le titre, je rajouterai simplement que je suis déjà parti c'est pas la peine de sortir les battes...

Suivre le flux des commentaires

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