[kernel] kenel panic suite à maj du 30/11 (résolu)

Reconnaissance et configuration du matériel / kernel linux
nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

[kernel] kenel panic suite à maj du 30/11 (résolu)

Message par nowahn » mar. 02 déc. 2008, 11:59

Bonjour à tous,

Suite à la maj du 30/11 (kernel26, xorg-server, nvidia entre autres), j'ai eu comme beaucoup de monde plusieurs problèmes :
  • 1) X qui ne démarre pas (résolu, option RgbPath n'est plus supportée dans xorg.conf)
  • 3) Quand je boote sur l'image normale, j'ai un kernel panic. C'est là que j'ai besoin d'aide
Précisions :
- l'image fallback boote sans problème
- mon système :
archlinux i686 en dualboot avec windows
processeur intel core2 duo
2 hdd sata en raid 0 (raid semi-matériel)
- pour gérer le raid, j'ai dans mon mkinicpio.conf :
* MODULES="... dm-mod"
* BINARIES="dmraid"
* HOOKS="... dmraid"
- il me semble avoir vu passer un message du genre "xxxxx compilé comme un module" pendant la mise à jour du noyau, mais je ne le retrouve pas dans pacman.log (ma piste étant qu'il y aurait un module de plus à charger que le hook "autodetect" empècherai)
- derniers messages avant le kernel panic :

Code : Tout sélectionner

Waiting for devices to settle ... done.
:: Initramfs Completed - control passing to kinit
IP-Config: no devices to configure
Waiting 0 s before mouting root device...
usb1-4: configuration #1 choosen from 1 choice
kinit: Unable to mount root fs on device dm-8(254,8)
kinit: init not found!
Kernel panic - not syncing: Attempted to kill init!
Quel est le problème avec mon image kernel26.img ?
(j'ai essayé de la refaire au cas où il y ait eu un problème lors de sa création :

Code : Tout sélectionner

mkinitcpio -g /boot/kernel26.img
, ça n'arrange rien)

Questions subsidiaires :
Les messages s'affichant lors du boot sont-ils enregistrés quelque part ? (après une recherche rapide dans /var/log, je ne les ai pas trouvé)
Certains messages affichés par pacman ne sont pas enregistrés dans pacman.log (les dépendances optionnelles, et le message sur le module cité plus haut), peut-on les retrouver ailleurs ?
Dernière modification par nowahn le dim. 07 déc. 2008, 16:44, modifié 1 fois.
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03
Contact :

Message par tuxce » mar. 02 déc. 2008, 14:41

salut, regarde si la commande:

Code : Tout sélectionner

hwdetect --hostcontroller
ne te sort pas un module supplémentaire par rapport à ce que tu as dans MODULES dans /etc/mkinitcpio.conf


Les messages du boot avant le démarrage de rc.sysinit se trouve dans /var/log/dmesg.log mais sont écrasés à chaque démarrage.

Les informations d'un paquet et notamment les dépendances optionnelles sont affichées avec:

Code : Tout sélectionner

pacman -Si pkg
ou s'il est déjà installé

Code : Tout sélectionner

pacman -Qi pkg

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » mar. 02 déc. 2008, 20:42

hwdetect donne la même liste que dans /etc/mkinitcpio.conf

Code : Tout sélectionner

# hwdetect --hostcontroller
MODULES="pata_acpi pata_amd ata_generic scsi_mod sata_nv"
j'ai essayé autre chose : j'ai démarré sur l'image normale avec l'option break=y dans la ligne kernel du menu grub

Code : Tout sélectionner

kernel ... break=y
dans le shell où on arrive, je peut voir que la série des fichiers /dev/dm-# et /dev/mapper/nvidia_blablablap# sont bien présents, mais si j'essaie de les monter ça ne marche pas

Code : Tout sélectionner

# mkdir mnt
# mount -t reiserfs /dev/dm-8 mnt # ma partition racine d'archlinux
mount: No such device
si je fait la même manipulation sur l'image fallback, la partition se monte correctement

Donc pour résumer, l'image fallback crée des fichier valides dans /dev alors que l'image normale crée des fichier à priori invalides

si vous avez des suggestions ...
Prends le temps de rêvasser, l'inspiration viendra ...

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » mer. 03 déc. 2008, 10:17

Suis-je le seul à avoir ce problème avec cettte mise à jour ?
Car pour les 2 premiers problèmes, j'ai pu résoudre le premier tout seul comme un grand :woohoo: et pour le deuxième il m'a suffit de chercher "qwerty" sur ce forum, mais aucune trace de ce problème de kernel panic.
La seule chose qui rende mon système un peu exotique, c'est mes 2 disques dur en raid 0, donc je suppose que ça doit avoir un lien.

Pour continuer mon diagnotic, toujours avec l'option break=y, j'ai regardé les modules chargés pendant le démarrage (en tapant lsmod dans le mini shell sur lequel on arrive).
Résultat : j'ai la même liste de modules sur les 2 images (normale et fallback). Donc je vois pas de problème de ce coté là.

Y at-il des commandes pour diagnostiquer les fichiers dans /dev puisqu'il semble qu'ils ne soient pas valides ?
Prends le temps de rêvasser, l'inspiration viendra ...

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » mer. 03 déc. 2008, 18:32

de plus en plus bizarre ...

j'ai continué à chercher la différence entre l'image normale et l'image fallback dans le shell où on tombe quand on met l'option break=y dans le menu grub

pour résumer mes résultats :
- je rajoute fsck.reiserfs à la ligne BINARIES de mon /etc/mkinitcpio.conf

Code : Tout sélectionner

BINARIES="... fsck.reiserfs"
- je fabrique l'image

Code : Tout sélectionner

# mkinitcpio -g /boot/kernel26.img
- je redémarre
- dans grub je rajoute l'option break=y à la ligne kernel

Code : Tout sélectionner

kernel ... break=y
- dans le shell où on arrive je vérifie le système de fichier sur ma partition racine, puis je tente de la monter

Code : Tout sélectionner

ramfs$ fsck.reiserfs --check /dev/dm-8
...
blablabla
...
Replaying journal..
Reiserfs journal '/dev/dm-8' in blocks [18..8211]: 0 transactions replayed
Checking Internal tree...
0%....20%....40%....60%....80%....100%
Checking Semantic tree...
There are on the filesystem:
	Leaves 19579
	Internal nodes 132
	Directories 9760
	Other files 92173
	Data block pointers 581061 (87 of them are zero)
	Safe links 0
No corruptions found
ramfs$ mkdir mnt
ramfs$ mount -t reiserfs /dev/dm-8 mnt
mount: No such device
ramfs$ exit
:: Initramfs Completed - control passing to kinit
IP-Config: no devices to configure
Waiting 0 s before mounting root device...
kinit: Unable to mount root fs on device dm-8(254,8)
kinit: init not found!
Kernel panic - not syncing: Attempted to kill init!
je fais la même manip, mais avec l'image fallback

Code : Tout sélectionner

# mkinitcpio -S autodetect -g /boot/kernel26-fallback.img
là la partition se monte correctement.

donc pour résumer :
- les 2 images (normale et fallback) créent des fichiers valides dans /dev pour mes partitions (fsck.reiserfs donnent exactement le même résultat)
- mount n'arrive pas à monter la partition sur l'image normale, mais y arrive sur l'image fallback

bref, là j'ai besoin d'aide parce que je sèche complètement ...
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
Grenshad
Hankyu
Messages : 31
Inscription : mar. 20 févr. 2007, 01:12
Contact :

Grub?

Message par Grenshad » jeu. 04 déc. 2008, 17:52

Il me semble avoir lu quelquepart qu'une màj de grub dernièrement a causé quelques souçis de boot dans certains cas.

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » jeu. 04 déc. 2008, 19:19

merci pour la suggestion Grenshad, mais ma dernière maj de grub date du 22/11 et mon système a démarré normalement entre le 22 et le 30/11.

j'ai continuer à avancé dans mon diagnostic :
j'ai fait la même manip que précédemment (vérification et tentative de montage d'une partition après un démarrage avec l'option "break=y"), mais avec une clé USB (en n'oubliant pas de rajouter le hook "usb" dans l'image)
- avec la clé formatée en reiserfs (comme ma partition racine)
=> vérification : OK sur les 2 images
=> montage : OK sur l'image fallback, échec sur l'image normale
- avec la clé formatée en ext2
=> vérification : OK sur les 2 images
=> montage : OK sur les 2 images

ce qui écarte un problème avec le fait que mon système soit sur des disques en raid

conclusion : le problème se joue quelque part entre :
- le hook autodetect (la seule différence entre les 2 images)
- la commande mount
- le système de fichier reiserfs

je m'en vais diagnostiquer plus en avant la commande mount (j'ai vu qu'il y a une option -v).
je vous tiens au courant, mais si vous avez des idées je suis preneur
Prends le temps de rêvasser, l'inspiration viendra ...

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » jeu. 04 déc. 2008, 21:47

a y est, j'ai résolu le problème :D

bon ,donc, je m'en allais pour faire un mount -v toujours sur le shell de l'option "break=y"

Code : Tout sélectionner

ramfs$ mkdir mnt
ramfs$ mount -v -t reiserfs /dev/dm-8 /mnt
et là, ça me dit que l'option -v est invalide.
je rajoute donc le binaire "mount" à l'image de démarrage et je recommence

Code : Tout sélectionner

ramfs$ mkdir mnt
ramfs$ mount -v -t reiserfs /dev/dm-8 /mnt
mount: unknown filesystem type 'reiserfs'
c'est quand même plus précis que le "no such device" du mount de base
là dessus je pars pour je sais plus quel test, mais avant je jette un coup d'oeil au man de mkinitcpio à la recherche d'une éventuelle option pour rajouter un binaire à l'image (raz le bol d'éditer /etc/mkinitcpio.conf). je trouve pas ce que je cherche mais je tombe sur l'option -s qui permet d'écrire dans un fichier la liste des fichiers inclus dans l'image.
l'occasion est trop bonne de comparer la différence entre l'image normale et l'image fallback
en comparant les 2 listes obtenues je vois qu'il y a un module reiserfs dans l'image fallback et pas dans l'image normale
je rajoute donc le module reiserfs à l'image normale et là youpi ça démarre.

donc pour conclure, pour résoudre mon problème j'ai juste à rajouter le module reiserfs à la ligne MODULES de mon /etc/mkinitcpio.conf

Code : Tout sélectionner

MODULES="... reiserfs"
(et refaire l'image avec mkinitcpio évidemment)

par contre si quelqu'un pouvait expliquer pourquoi j'ai besoin de ce module maintenant et pas avant la maj ...
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03
Contact :

Message par tuxce » jeu. 04 déc. 2008, 22:16

j'allais te le proposer mais vu que le fsck passait, je me suis abstenu, du coup, je me demande comment fait fsck sans le module...

pour ce qui est de avant la maj et après, peut etre que klibc ne reconnait pas le type de ta partition:
en root et par exemple si ton / est sda1:

Code : Tout sélectionner

/usr/lib/klibc/bin/fstype < /dev/sda1

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » ven. 05 déc. 2008, 15:07

merci tuxce, voila le résultat de la commande :

Code : Tout sélectionner

# /usr/lib/klibc/bin/fstype < /dev/mapper/nvidia_bafgafdap11 # ma partition racine
FSTYPE=reiserfs
FSSIZE=107372740608
bref ça marche, mais comme le système est démarré et que le module reiserfs est chargé c'est plutot normal
je fait donc une image de démarrage sans le module reiserfs et avec le binaire "/usr/lib/klibc/bin/fstype" ainsi que "mount" (pour avoir un meilleur diagnostic) et je démarre dessus avec l'option break=y

Code : Tout sélectionner

ramfs$ /usr/lib/klibc/bin/fstype < /dev/mapper/nvidia_bafgafdap11
FSTYPE=reiserfs
FSSIZE=107372740608
ramfs$ mkdir mnt
ramfs$ mount -t reiserfs /dev/mapper/nvidia_bafgafdap11 mnt
mount: unknown filesystem type 'reiserfs'
ramfs$ lsmod
...
...
... # pas de reiserfs
note sur l'image fallback, lsmod ne mentionne pas reiserfs au début, mais le mentionne après le montage d'une partition reiserfs (qui réussi)

donc fstype connait reiserfs sans avoir besoin du module reiserfs, mais mount en a besoin. je ne sais pas quoi en conclure ...

mais il y a plus étrange : j'ai sur mon système une petite partition avec un système archlinux que je mets jamais à jour qui est là pour ne pas avoir besoin du CD d'installation pour réparer mon système quand je le mets en carafe (comme je suis un peu débutant sur les bords et que j'aime bien expérimenter ça m'arrive régulièrement :lol: )
bref ce système à été installé vers le 15/11 en FTP/HTTP (CD 2008.06, toujours en 32bit). l'image normale démarre sans kernel panic.
pour savoir si le module reisefs est présent dans cette image, je démarre avec l'option break=y et

Code : Tout sélectionner

ramfs$ lsmod
...
... # pas de reiserfs
ramfs$ mkdir mnt
ramfs$ mount -t reiserfs /dev/mapper/nvidia_bafgafdap11 mnt # ça marche
ramfs$ lsmod
...
reiserfs
...
bref c'est le comportement normal
puis, pour voir si l'image normale sur ce système non mis à jour contient un fichier "reiserfs" et n'ayant pas eu l'idée de noter où il est, je décide de refaire l'image normale avec le binaire "find" (heureusement, ça fait quelques jour que je fait une image /boot/kernel26-test.img pour tous mes test)
je redémarre sur cette image avec l'otion break=y, je fait mon find et pas de trace de "reiserfs", je fais exit pour continuer le démarrage et la surprise : kernel panic (le même)
bref, après vérification, même sur ce système que je n'ai pas mis à jour depuis l'installation, la fabrication de l'image de démarrage normale n'inclut pas le module "reiserfs", alors qu'il a été inclus au moment de l'installation

la seule question qui me viens est quel mkinitcpio est utilisé par le script d'installation, celui du CD ou celui qui vient d'être installé (même question pour tous les utilitaires appelés par mkinitcpio puisque après vérification le paquet mkinitcpio n'a pas évolué depuis la version présente sur le CD)

autre chose, en recentrant mes recherche sur reiserfs plutot que sur la maj du 30/11, je suis enfin (peut-être) tombé sur quelqu'un qui a le même problème (en tout cas c'est le même kernel panic et c'est sur un système sur reiserfs) mais le problème est apparu il y a 1 mois
voici le lien vers le post : http://bbs.archlinux.org/viewtopic.php?id=58060
j'attends des réponse pour savoir si c'est le même problème
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03
Contact :

Message par tuxce » ven. 05 déc. 2008, 16:00

fstype n'a pas besoin du module pour reconnaitre les partitions (pour le fsck, je sais toujours pas :/), il n'est pas lancé pendant le initrd, il est utilisé par autodetect pendant le mkinitcpio pour définir les modules à intégrer dans l'image générée.

mais la, je vois de moins en moins ...
un autre test que tu peux faire, c'est simuler l'autodetect pour voir si c'est vraiment lui qui va pas, en root:

Code : Tout sélectionner

source /lib/initcpio/functions 
source /lib/initcpio/install/autodetect 
MODULEDIR=/lib/modules/$(uname -r)
install
cat /autodetect_modules
# tu peux effacer ce fichier par la suite
si tu n'as pas reiserfs dedans, tu peux suivre ce que install fait en lancant:

Code : Tout sélectionner

set -x
install
set +x
pour l'image que tu as crée sur le système non mis à jour, est que tu l'as fait après maj ?

EDIT: j'oubliais, juste pour info:

Code : Tout sélectionner

gzip -dc <image_initrd> | cpio -id --no-absolute-filenames
permet de décompresser l'image pour voir ce qu'il y a dedans.
Dernière modification par tuxce le ven. 05 déc. 2008, 19:44, modifié 1 fois.

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » ven. 05 déc. 2008, 18:17

oulà là ça commence à dépasser mon niveau :shock:

bon, quand je fais le premier test, j'entends bien que ça travaille pendant la commande "install" (environ une demi-seconde), mais ça me crée pas le fichier "/autodetect_modules" et find me dit qu'aucun fichier n'a été modifé les 5 dernières minutes (à part quelques fichiers dans /dev)

le deuxième test, ça me sort une sortie qui défile et que j'ai pas le temps de voir, j'arrive pas à la rediriger vers un fichier

pour l'image sur le système non mis à jour, je ne l'ai toujours pas mis à jour. pour essayer d'être clair :
- j'ai installer ce système vers le 15/11
- l'image normale construite au moment de l'installation (sans indiquer le module "reiserfs" dans /etc/mkinitcpio.conf) démarre normalement et contient le module "reiserfs"
- une image "normale" (c'est-à-dire avec le hook "autodetect" et sans mentionner le module "reiserfs") construite aujourd'hui sur ce même système non mis à jour depuis l'installation ne démarre pas et ne contient pas le module "reiserfs"
- une image "normale" (c'est-à-dire avec le hook "autodetect"), mais en mentionnant le module "reiserfs" dans /etc/mkinitcpio.conf, construite aujourd'hui sur ce même système non mis à jour depuis l'installation démarre normalement et contient le module "reiserfs"

et je te rassure , moi aussi je vois de moins en moins :?
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03
Contact :

Message par tuxce » ven. 05 déc. 2008, 19:44

dsl, je me suis gourré sur le recopie des commandes, il manquait un espace entre uname et -r (mais t'as du le voir, non?)

si meme avec la correction tu n'as rien, tu peux mettre sur pastebin la sortie de install avec le "set -x", merci.
(mais pas avec une redirection, il faut copier/coller)

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » ven. 05 déc. 2008, 23:11

j'avias bien compris pour uname -r :wink:
j'ai mis la sortie de install entre les set -x / +x ici
http://pastebin.archlinux.fr/264486
je confirme que ça crée aucun fichier
Prends le temps de rêvasser, l'inspiration viendra ...

Avatar de l’utilisateur
Skunnyk
Maître du Kyudo
Messages : 1120
Inscription : mer. 06 sept. 2006, 21:31
Localisation : IRC
Contact :

Message par Skunnyk » ven. 05 déc. 2008, 23:51

Je ne sais pas si cela va aider, mais j'ai aussi mon / en reiserfs sur mon fixe (je n'ai cependant eu aucun problème suite à des mises à jours ces derniers temps).
A l'époque, lors du passage à initcpio , une des instructions pour bien remplir le mkinitcpio.conf était de lancer mkinitcpio -M.
Et là, je me retrouvais avec reseirfs dans la liste des modules. Comme je n'utilise pas le hook filesystem, j'ai du rajouter reiserfs à la ligne MODULES.
Donc au final, est ce que tu utilises le hook filesystem ? .
Je te l'accorde, ça ne resoud pas le problème du 'pourquoi ca fonctionnait avant' ;-)

Avatar de l’utilisateur
tuxce
Maître du Kyudo
Messages : 6677
Inscription : mer. 12 sept. 2007, 16:03
Contact :

Message par tuxce » sam. 06 déc. 2008, 00:17

ok, je crois que j'ai saisi, c'est un concours de circonstance et en même temps, un petit bug que tu devrais reporter sur bugs.archlinux.org.

le système d'autodetection liste les fichiers de type block, enleve les "loop", ceux en ram et les disquettes "fd", or ton disque a pour nom:

Code : Tout sélectionner

/dev/mapper/nvidia_bafgafdap11
il y a un "fd" dedans, la partition est donc enlevée par le

Code : Tout sélectionner

grep -v -e loop -e ram -e fd
qui est dans /lib/initcpio/install/autodetect
si tu le changes par:

Code : Tout sélectionner

grep -v -e /loop -e /ram -e /fd
il devrait prendre en compte ta partition et en trouver le système de fichier.
Dernière modification par tuxce le dim. 07 déc. 2008, 18:36, modifié 1 fois.

Cactus
Maître du Kyudo
Messages : 2073
Inscription : sam. 16 sept. 2006, 10:39
Localisation : 31 - Toulouse Nord

Message par Cactus » sam. 06 déc. 2008, 10:26

Skunnyk a écrit :Je ne sais pas si cela va aider, mais j'ai aussi mon / en reiserfs sur mon fixe (je n'ai cependant eu aucun problème suite à des mises à jours ces derniers temps).
A l'époque, lors du passage à initcpio , une des instructions pour bien remplir le mkinitcpio.conf était de lancer mkinitcpio -M.
Et là, je me retrouvais avec reseirfs dans la liste des modules. Comme je n'utilise pas le hook filesystem, j'ai du rajouter reiserfs à la ligne MODULES.
Donc au final, est ce que tu utilises le hook filesystem ? .
Je te l'accorde, ça ne resoud pas le problème du 'pourquoi ca fonctionnait avant' ;-)
J'y ai pensé hier soir en éteignant mon PC, tu m'as devancé.
Moi aussi, le / est en reiserfs, et j'ai le hook 'filesystems' (avec un s à la fin) et aucun pb avec l'initrd.
Par conte, je n'ai jamais de soucis avec ça. :roll:

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » sam. 06 déc. 2008, 11:19

merci tuxce, ta modification marche :D

pour ceux qui ont pas suivi, il s'agit d'editer le fichier /lib/initcpio/install/autodetect comme indiqué dans le dernier post de tuxce (recherchez fd dans le fichier, il apparait qu'une fois)

comme toutes mes partitions on la forme "nvidia_bafgafdap#", aucune n'était testée par autodetect, donc le système de fichier reiserfs apparaissait inutile

donc mon bug n'est pas spécialement lié à reiserfs (si mon système avait été en ext2, à priori y aurait pas eu de bug car mount semble ne pas avoir besoin de module pour ça, par contre d'autres systèmes de fichiers peuvent êtres concernés)

le seul problème, c'est la présence de "loop", "ram" ou "fd" dans le nom des partitions

reste une question : pourquoi ça marchait avant ? mes partitions se sont toujours appelées "nvidia_bafgafdap#" (enfin pour être précis ça fait 1 mois que j'ai ce PC, et au début y avait pas le "p" devant le numéro jusqu'à une maj du paquet "dmraid", mais le bug n'est pas apparu à ce moment-là) et j'ai toujours utilisé reiserfs
j'ai comparé les fichiers /lib/initcpio/install/autodetect sur mon système qui buguait, sur mon système non mis à jour et celui sur le CD d'installation, ils sont tous identiques.
je m'en vais faire une installation sur un bout de disque qu'il me reste pour voir s'il y a d'autres noms dans /dev au moment de l'installation
Skunnyk a écrit :Je ne sais pas si cela va aider, mais j'ai aussi mon / en reiserfs sur mon fixe (je n'ai cependant eu aucun problème suite à des mises à jours ces derniers temps).
A l'époque, lors du passage à initcpio , une des instructions pour bien remplir le mkinitcpio.conf était de lancer mkinitcpio -M.
Et là, je me retrouvais avec reseirfs dans la liste des modules. Comme je n'utilise pas le hook filesystem, j'ai du rajouter reiserfs à la ligne MODULES.
Donc au final, est ce que tu utilises le hook filesystem ? .
Je te l'accorde, ça ne resoud pas le problème du 'pourquoi ca fonctionnait avant' :wink:
j'ai aussi le hook "filesystems" dans mon mkinitcpio.conf
Prends le temps de rêvasser, l'inspiration viendra ...

nowahn
archer de cavalerie
Messages : 172
Inscription : lun. 04 août 2008, 19:03
Localisation : ailleurs

Message par nowahn » sam. 06 déc. 2008, 14:57

bon, j'ai fait le test de faire une installation (via ftp/http, j'ai un liveCD 2008.06-ftp-i686)
l'image normale ne démarre pas (le même kernel panic), tout ça avec la même procédure d'installation qui fabriquait une image fonctionnelle le 18/11 (date où j'avais installé mon système courant et celui que j'ai jamais mis à jour)
de plus, j'ai vérifier à diférentes étapes de l'installation, j'ai toujours le résultat suivant :

Code : Tout sélectionner

# find /dev/ -type b -print | grep -v -e loop -e ram -e fd # la commande en cause dans le hook "autodetect"
sda2
sda1
sr0
sda
sdb
# /usr/lib/klibc/bin/fstype < /dev/sda2
stdin: error 0
# /usr/lib/klibc/bin/fstype < /dev/sda1
FSTYPE=unknown
FSSIZE=0
# /usr/lib/klibc/bin/fstype < /dev/sr0
FSTYPE=iso9660
FSSIZE=0
# /usr/lib/klibc/bin/fstype < /dev/sda
FSTYPE=unknown
FSSIZE=0
# /usr/lib/klibc/bin/fstype < /dev/sdb
FSTYPE=unknown
FSSIZE=0
donc le hook "autodetect" n'a pas de raison d'inclure le module reiserfs, mais il l'a fait lors des installation du 18/11 et des multiples installations que j'ai fait avant ça

donc une hypothèse serait que le 18/11, d'autres fichiers étaient crées dans /dev en plus des "/dev/mapper/nvidia_bafgafdap#", qui permettait à autodetect de détecter reiserfs
note : dans l'image de démarrage (le shell de l'option "break=y") il y a dans /dev les fichiers /dev/mapper/nvidia_bafgafdap#, mais également des fichiers /dev/dm-# qui désignent les mêmes partitions, les messages de démarrage indiques d'ailleurs toujours le montage des /dev/dm-# et pas ceux des /dev/mapper/nvidia_bafgafdap# alors que ce sont bien ces derniers qui sont dans /etc/fstab. ces fichiers (/etc/dm-#) ne sont pas présent dans le système une fois démarré.

mais il y a un hic à cette hypothèse : mon système non mis à jour
aucun fichier n'a changé sur ce système depuis son installation le 18/11 et il n'inclus plus le module reiserfs aujourd'hui alors qu'il l'a fait le 18/11 ... plus je réfléchis, moins je comprends ...
Prends le temps de rêvasser, l'inspiration viendra ...

Cactus
Maître du Kyudo
Messages : 2073
Inscription : sam. 16 sept. 2006, 10:39
Localisation : 31 - Toulouse Nord

Message par Cactus » sam. 06 déc. 2008, 22:38

chapeau bas pour avoir résolu le problème... c'était loin d'être évident ! :altere:

Répondre