Le 17-02-2015, Pim nous expliquait dans
fr.comp.os.linux.configuration
() :Et depuis que j'ai recompilé le noyau, j'ai toujours un
"kernel panic" que je mette ou pas l'initrd.
Il doit manquer un truc mais quoi?
Le support pour le système de fichier utilisé pour la partition racine ?
Le support pour la type de partition utilisé ?
L'autre jour j'ai lutté quelques heures avant de m'apercevoir que
j'avais oublié le support pour m'apercevoir que je n'avais
pas coché le support pour "l'hologe temps réel" (CONFIG_RTC_CLASS) ce
qui n'empéchait en rien la compilation du noyau ni son fonctionement mais
rendait le driver de la carte wifi inopérant bien que le module se
chargeait/déchargeait sans problème.A noter que sous debian : il pourrai peut-etre s'agir aussi
d'une procédure particulière de la génération de l'initrd.
Houlà... Moi... Debian...Est-ce que grub peut intérragir sur ce processus?
Je suis en grub2 et je trouve que c'est lourd comme boot loader,
pour ce que ça fait.
Houlà... Moi.. Grub2...
:)Alors , déjà j'avais oublié CONFIG_BLK_DEV_SD=y et forcément sans cela
aucune chance de reconnaitre la partition racine.
Mais en l'y ajouter : toujours pareil : ça commence à être gonflant!
Scrogneugneu!
Je me demande s'il n'y a pas une option pour reconnaitre les uuid
car mon grub demande l'uuid du disque et non /dev/sdxx .
Je ne crois pas et au pire il suffit de modifier fstab en conséquence
pour vérifier.Bon ça je pourrais le tester en changant dans grub mais j'en ai
marre de bidouiller.
Alors je propose de poser mon .config ici:
Et peut-être que vous pourriez voir ce qui peut manquer.
Difficile à dire sans connaître le matériel sur lequel ce noyau est
sensé tourner ni plus de détail sur la panique.
--
Doug
Le 17-02-2015, Pim nous expliquait dans
fr.comp.os.linux.configuration
(<slrnme6l53.3b3.moi@Amd64.Mydomain.net>) :
Et depuis que j'ai recompilé le noyau, j'ai toujours un
"kernel panic" que je mette ou pas l'initrd.
Il doit manquer un truc mais quoi?
Le support pour le système de fichier utilisé pour la partition racine ?
Le support pour la type de partition utilisé ?
L'autre jour j'ai lutté quelques heures avant de m'apercevoir que
j'avais oublié le support pour m'apercevoir que je n'avais
pas coché le support pour "l'hologe temps réel" (CONFIG_RTC_CLASS) ce
qui n'empéchait en rien la compilation du noyau ni son fonctionement mais
rendait le driver de la carte wifi inopérant bien que le module se
chargeait/déchargeait sans problème.
A noter que sous debian : il pourrai peut-etre s'agir aussi
d'une procédure particulière de la génération de l'initrd.
Houlà... Moi... Debian...
Est-ce que grub peut intérragir sur ce processus?
Je suis en grub2 et je trouve que c'est lourd comme boot loader,
pour ce que ça fait.
Houlà... Moi.. Grub2...
:)
Alors , déjà j'avais oublié CONFIG_BLK_DEV_SD=y et forcément sans cela
aucune chance de reconnaitre la partition racine.
Mais en l'y ajouter : toujours pareil : ça commence à être gonflant!
Scrogneugneu!
Je me demande s'il n'y a pas une option pour reconnaitre les uuid
car mon grub demande l'uuid du disque et non /dev/sdxx .
Je ne crois pas et au pire il suffit de modifier fstab en conséquence
pour vérifier.
Bon ça je pourrais le tester en changant dans grub mais j'en ai
marre de bidouiller.
Alors je propose de poser mon .config ici:
Et peut-être que vous pourriez voir ce qui peut manquer.
Difficile à dire sans connaître le matériel sur lequel ce noyau est
sensé tourner ni plus de détail sur la panique.
--
Doug
Le 17-02-2015, Pim nous expliquait dans
fr.comp.os.linux.configuration
() :Et depuis que j'ai recompilé le noyau, j'ai toujours un
"kernel panic" que je mette ou pas l'initrd.
Il doit manquer un truc mais quoi?
Le support pour le système de fichier utilisé pour la partition racine ?
Le support pour la type de partition utilisé ?
L'autre jour j'ai lutté quelques heures avant de m'apercevoir que
j'avais oublié le support pour m'apercevoir que je n'avais
pas coché le support pour "l'hologe temps réel" (CONFIG_RTC_CLASS) ce
qui n'empéchait en rien la compilation du noyau ni son fonctionement mais
rendait le driver de la carte wifi inopérant bien que le module se
chargeait/déchargeait sans problème.A noter que sous debian : il pourrai peut-etre s'agir aussi
d'une procédure particulière de la génération de l'initrd.
Houlà... Moi... Debian...Est-ce que grub peut intérragir sur ce processus?
Je suis en grub2 et je trouve que c'est lourd comme boot loader,
pour ce que ça fait.
Houlà... Moi.. Grub2...
:)Alors , déjà j'avais oublié CONFIG_BLK_DEV_SD=y et forcément sans cela
aucune chance de reconnaitre la partition racine.
Mais en l'y ajouter : toujours pareil : ça commence à être gonflant!
Scrogneugneu!
Je me demande s'il n'y a pas une option pour reconnaitre les uuid
car mon grub demande l'uuid du disque et non /dev/sdxx .
Je ne crois pas et au pire il suffit de modifier fstab en conséquence
pour vérifier.Bon ça je pourrais le tester en changant dans grub mais j'en ai
marre de bidouiller.
Alors je propose de poser mon .config ici:
Et peut-être que vous pourriez voir ce qui peut manquer.
Difficile à dire sans connaître le matériel sur lequel ce noyau est
sensé tourner ni plus de détail sur la panique.
--
Doug
Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
Nicolas George a écrit :
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Nicolas George a écrit :
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Nicolas George a écrit :
« (0,0) », c'est que le noyau n'a pas réussi à traduire le nom de la
partition racine en couple majeur-mineur. Ça peut être que l'information
n'est pas renseignée, que le driver du contrôleur n'est pas compilé en dur,
ou bien encore que le label ou l'UUID n'a pas été trouvé -- ce dernier point
pouvant encore venir d'un driver manquant.
A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Le 17-02-2015, Pim a écrit :Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
Le 17-02-2015, Pim <moi@free.fr> a écrit :
Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
Le 17-02-2015, Pim a écrit :Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
Le 18 Feb 2015 14:06:27 GMT,
Kevin Denis disait ceci :Le 17-02-2015, Pim a écrit :Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
grep DEV_SD .config
CONFIG_BLK_DEV_SD=y
grep -E "SCSI.+?=y" .config
CONFIG_CISS_SCSI_TAPE=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_ISCSI_IBFT_FIND=y
Mais peut-être que ce n'est pas correct ou qu'il en manque.
Je ne peux pas copier tout le .config. a moins de la mettre
sur paste.com. mais bon!
Merci pour ton aide.
Le 18 Feb 2015 14:06:27 GMT,
Kevin Denis <kevin@nowhere.invalid> disait ceci :
Le 17-02-2015, Pim <moi@free.fr> a écrit :
Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
grep DEV_SD .config
CONFIG_BLK_DEV_SD=y
grep -E "SCSI.+?=y" .config
CONFIG_CISS_SCSI_TAPE=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_ISCSI_IBFT_FIND=y
Mais peut-être que ce n'est pas correct ou qu'il en manque.
Je ne peux pas copier tout le .config. a moins de la mettre
sur paste.com. mais bon!
Merci pour ton aide.
Le 18 Feb 2015 14:06:27 GMT,
Kevin Denis disait ceci :Le 17-02-2015, Pim a écrit :Il me dit : on unknown block (0,0) en gros qu'il ne trouve
pas ma partition racine.
(0,0) si je ne me trompe pas, c'est la première partition du
premier disque.
Du coup, est-ce que tu as mis le pilote du disque dur?
Ou le block layer? Ou l'émulation SCSI?
--
Kevin
grep DEV_SD .config
CONFIG_BLK_DEV_SD=y
grep -E "SCSI.+?=y" .config
CONFIG_CISS_SCSI_TAPE=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_ISCSI_IBFT_FIND=y
Mais peut-être que ce n'est pas correct ou qu'il en manque.
Je ne peux pas copier tout le .config. a moins de la mettre
sur paste.com. mais bon!
Merci pour ton aide.
Pascal Hambourg disait ceci :A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Pascal Hambourg disait ceci :A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.
Pim a écrit :Pascal Hambourg disait ceci :A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
C'est bien pour cela qu'on utilise préférentiellement les UUID
maintenant, donc un initrd ou initramfs.et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pas compris ce que tu veux dire.Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement
récent, le noyau ne gère pas les UUID.
Pim a écrit :
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.
Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
C'est bien pour cela qu'on utilise préférentiellement les UUID
maintenant, donc un initrd ou initramfs.
et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pas compris ce que tu veux dire.
Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement
récent, le noyau ne gère pas les UUID.
Pim a écrit :Pascal Hambourg disait ceci :A moins que ça ait changé (ce qui est fort possible, j'avais cru lire
une annonce dans ce sens), le noyau ne gère pas les UUID de système de
fichiers. C'est le travail de l'initrd/initramfs, généralement avec
udev. Cette erreur peut donc se produire quand la racine est spécifiée
par UUID, LABEL ou autre identifiant du même tonneau et qu'un
initrd/initramfs n'a pas été chargé.
Donc si ça avait changé comme tu l'indiques, il ne serait plus possible
de faire un noyau monolitique sans initrd sauf si on utilise
/dev/[sh]d[0-9]+ comme identification de la partition racine.
Au contraire, ce serait maintenant possible alors que ça ne l'était pas
jusqu'ici.Ce qui n'est pas du tout dynamique: si tu intervertis tes disques dans
ton système ou la config du BIOS,
tu devra modifier la conf de ton boot-loader
pour lui indiquer un autre périphérique de disque
C'est bien pour cela qu'on utilise préférentiellement les UUID
maintenant, donc un initrd ou initramfs.et cela voudrai dire que le support des uuid deviendrai
alors obsolète dans ce cas.
Pas compris ce que tu veux dire.Pour ma part: je ne crois pas à cette hypothèse car je ne crois pas
un seul instant que les développeurs du noyaux Linux
auraient permis ces regresssions.
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement
récent, le noyau ne gère pas les UUID.