Forum Linux.debian/ubuntu kernel panic

Posté par  .
Étiquettes :
0
26
fév.
2006
Salut,

Une debian etch sur un portable (asus L3000D), installée de longue date (sarge, puis etch), mise à jour régulière...
Ce matin au boot : kernel panic!! pour être précis (copié à la main) :

RAMDISK: couldn't find valid RAMdisk image starting at 0
VFS: cannot open root device "303" or unknown-block (3,3)
Please append a correct "root"=boot option
Kernel panic - not syncing : VFS Unable to mount root fs or unknown-block (3,3)

Ça ressemble à un problème de reconnaissance du disque dur. Toutefois, ce n'est pas un noyau maison, mais un noyau de l'archive debian. De plus, j'ai pu démarrer avec un ancien noyau (voir lilo.conf plus bas). et tenter de calmer cette panique... rien à faire donc je me tourne vers vous.

Le noyau actuel (2.6.15-1-K7) fonctionnait jusqu'à hier. J'ai sûrement fait une mise à jour hier (y'a t'il un journal qui garde une trace des apt-trucs?), du moins, d'après /var/log/apt/archives ces paquets (qui me paraissent sensibles) ont été modifiés récemment :

udev_0.084-5_i386.deb
initscripts_2.86.ds1-12_i386.deb
sysvinit_2.86.ds1-12_i386.deb
sysv-rc_2.86.ds1-12_all.deb

J'ai aussi installé récemment discover_2 (et désinstaller aujourd'hui mais ça ne change rien). Je ne sais pas où agir pour utiliser à nouveau la version 2.6.15 du noyau.

Voici quelques information supplémentaires.

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

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

#au cas ou (celui qui me sauve :)
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

fstab (la partie intéressante)
^^^^
/dev/hda3 / ext2 defaults,errors=remount-ro 0 1
/dev/hda1 /home ext2 defaults 0 2
/dev/hda4 none swap sw 0 0

Comment débloquer cela ?
Merci pour vos contributions.
  • # /var/log/dpkg.log

    Posté par  . Évalué à 3.

    (y'a t'il un journal qui garde une trace des apt-trucs?)
    hum, au temps pour moi, j'avais déjà posé cette question et obtenu une réponse :
    http://linuxfr.org/comments/651998.html#651998

    D'ailleurs :
    grep upgrade /var/log/dpkg.log| grep 2006-02-25
    me donne entre autre
    2006-02-25 14:35:48 upgrade initramfs-tools 0.51 0.52b

    et apt-cache show initramfs-tools
    This package contains tools to create and boot an initramfs for prepackaged
    2.6 Linux kernel. The initramfs is an cpio archive. At boot time, the kernel
    unpacks that archive into ram, mounts and uses it as initial root file system.
    From there on the mounting of the real root file system occurs in user space.
    klibc handles the boot-time networking setup. Supports nfs root system.
    Any boot loader with initrd support is able to load an initramfs archive.

    Ça pourrait être ça ? Mais que faire ??
  • # Question ....

    Posté par  . Évalué à 2.

    Pourquoi le noyau qui marche est dans le répertoire /boot (image=/boot/vmlinuz-2.6.12-1-k7) avec le ramdisk (initrd=/boot/initrd.img-2.6.12-1-k7) et pas celui qui ne marche pas (image=/vmlinuz et initrd=/initrd.img) ?
    • [^] # Re: Question ....

      Posté par  . Évalué à 2.

      "Très bonne question que je me suis posé aussi" ou comment on va en venir à lever une part du mystère.

      Les systèmes debian utilisent des liens symboliques /vmlinuz et /initrd.img placés à la racine est qui pointent vers un noyau placé dans /boot. Cela permet, entre autre, de mettre à jour le noyau par apt-get sans avoir à relancer un certain nombre de choses, comme lilo par exemple. (Par contre, pourquoi les placer dans / et non dans /boot/ ?, je ne sais pas, mais qu'importe, habituellement, ça marche).

      Voici comment ils se présentent :
      ls -l /
      lrwxrwxrwx 1 root root 25 2006-02-26 20:13 /vmlinuz -> /boot/vmlinuz-2.6.15-1-k7
      lrwxrwxrwx 1 root root 28 2006-02-26 20:12 /initrd.img -> /boot/initrd.img-2.6.15-1-k7

      On remarquera que ces liens ont été recréés tout récemment. En effet, j'en suis venu à la conclusion que le problème ne pouvait pas venir d'un autre paquet puisque les deux noyaux utilisaient les même briques systèmes. J'ai donc cherché les différences autour du noyau. Et celle dont tu parles saute aux yeux une fois qu'on l'a vue ;)
      J'ai essayé le noyau 2.6.15 sans les liens :

      image=/boot/vmlinuz-2.6.15-1-k7
      label=Linux-direct
      initrd=/boot/initrd.img-2.6.15-1-k7


      et ça fonctionnait ! Gloria, j'ai donc reformé les liens
      #ln -s /boot/vmlinuz-2.6.15-1-k7 /vmlinuz
      etc...

      Et hop, don't panic, serviette sur l'epaule, en rang par deux, rompez!

      Conclusion partielle où l'on voit que l'autre partie du mystère n'a rien perdu de sa profondeur.
      Maintenant, pour les debianistes de haut vol et les ceux qui savent, qu'est ce qui a pu perturber entre hier et aujourd'hui ces deux petits liens symboliques qui ne demandaient rien à personne ? Je précise à toutes fins utiles que je ne travaille pas en root à longueur de journée, que j'utilise même sudo avec des règles un peu strict et que je n'avais pas (aujourd'hui mise à part) tripoté mon kernel ou lilo depuis pas mal de temps.
      Si tu m'as lu jusque là et que tu as une idée sur la question, partage la.
      Merci
      • [^] # Re: Question ....

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

        Cela permet, entre autre, de mettre à jour le noyau par apt-get sans avoir à relancer un certain nombre de choses, comme lilo par exemple.

        A l'occasion, si tu as le temps, tu devrais essayer grub; ça à quand même pas mal d'avantages dans ce genre de situations.
        • [^] # Re: Question ....

          Posté par  . Évalué à 2.

          Bonne remarque :)
          J'utilise Grub sur ubuntu puisqu'il est là par défaut et en effet, il me plait. Mais bon, lilo est installé sur ma debian, alors quand j'aurais le temps...

Suivre le flux des commentaires

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