Je ne suis pas débutant sous Linux : partique depuis 1997.
j'ai voulu compiler mon noyaux Linux 3.2.65 sans initrd,
ce que j'ai fait des centaines de fois avec les noyaux 2.xxx
sans probleme.
Mais là avec cette version : il persiste à me faire une
initrd malgré les options que je lui met.
Alors s'il y a un forum spécifique au noyau Linux (version 3),
je suis preneur.
Le Fri, 20 Feb 2015 22:26:34 +0100, Pascal Hambourg disait ceci :
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.
Cela fait bien pas loin de 10 Ans : la "Damn Small Linux" qui boote sur Cdrom gérait déjà les UUID.
Peut-être la Knoppix aussi!
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire donc c'est bien lui qui gère les uuids ou alors je me trompe (ce qui n'est pas impossible), mais qu'on m'explique alors...
Le Fri, 20 Feb 2015 22:26:34 +0100,
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.
Cela fait bien pas loin de 10 Ans : la "Damn Small Linux" qui boote
sur Cdrom gérait déjà les UUID.
Peut-être la Knoppix aussi!
Après pour reconnaitre une partition racine en uuid, seul le
noyau peut le faire donc c'est bien lui qui gère
les uuids ou alors je me trompe (ce qui n'est pas impossible),
mais qu'on m'explique alors...
Le Fri, 20 Feb 2015 22:26:34 +0100, Pascal Hambourg disait ceci :
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.
Cela fait bien pas loin de 10 Ans : la "Damn Small Linux" qui boote sur Cdrom gérait déjà les UUID.
Peut-être la Knoppix aussi!
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire donc c'est bien lui qui gère les uuids ou alors je me trompe (ce qui n'est pas impossible), mais qu'on m'explique alors...
Nicolas George
Pim , dans le message , a écrit :
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire
Ah ?
Pim , dans le message <slrnmeffg2.8kj.moi@Amd64.Mydomain.net>, a écrit :
Après pour reconnaitre une partition racine en uuid, seul le
noyau peut le faire
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire
Ah ?
Pascal Hambourg
Nicolas George a écrit :
Pascal Hambourg , dans le message <mc88qb$1n8o$, a écrit :
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.
Tu as peut-être raté un petit bout.
Non car je répondais à "si ça avait changé", c'est-à-dire si maintenant le noyau gérait les UUID. Auparavant, il n'a jamais été possible d'utiliser un UUID pour la racine sans initrd ou initramfs.
Nicolas George a écrit :
Pascal Hambourg , dans le message <mc88qb$1n8o$1@saria.nerim.net>, a
écrit :
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.
Tu as peut-être raté un petit bout.
Non car je répondais à "si ça avait changé", c'est-à-dire si maintenant
le noyau gérait les UUID. Auparavant, il n'a jamais été possible
d'utiliser un UUID pour la racine sans initrd ou initramfs.
Pascal Hambourg , dans le message <mc88qb$1n8o$, a écrit :
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.
Tu as peut-être raté un petit bout.
Non car je répondais à "si ça avait changé", c'est-à-dire si maintenant le noyau gérait les UUID. Auparavant, il n'a jamais été possible d'utiliser un UUID pour la racine sans initrd ou initramfs.
Pascal Hambourg
Pim a écrit :
Pascal Hambourg disait ceci :
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais je ne crois pas que ce suport doit être dans l'initrd ou qu'il faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas confondre l'UUID d'une partition (défini dans la table de partition du disque) avec l'UUID du système de fichiers qu'elle contient (dans les méta-données du système de fichiers), qu'on utilise avec root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques partitionnés au format GPT mais pas avec les disques partitionnés au format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis la version 3.2 le noyau peut construire des UUID de partitions pour les disques au format MS-DOS à partir de l'identifiant unique (signature) du disque stocké dans le MBR et du numéro de la partition, par exemple 0002dd75-01 pour la première partition si 0002dd75 est la signature du disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la version 3.2, on peut spécifier un offset pour désigner la racine avec la syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée. Je ne sait pas comment désactiver ceci sous Debian. Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé le noyau est content car il a une racine. C'est l'initrd qui va râler s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement
récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais
je ne crois pas que ce suport doit être dans l'initrd ou qu'il
faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du
support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la
syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas
confondre l'UUID d'une partition (défini dans la table de partition du
disque) avec l'UUID du système de fichiers qu'elle contient (dans les
méta-données du système de fichiers), qu'on utilise avec
root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques
partitionnés au format GPT mais pas avec les disques partitionnés au
format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis
la version 3.2 le noyau peut construire des UUID de partitions pour les
disques au format MS-DOS à partir de l'identifiant unique (signature) du
disque stocké dans le MBR et du numéro de la partition, par exemple
0002dd75-01 pour la première partition si 0002dd75 est la signature du
disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la
version 3.2, on peut spécifier un offset pour désigner la racine avec la
syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la
n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas
avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée.
Je ne sait pas comment désactiver ceci sous Debian.
Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien
sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé
le noyau est content car il a une racine. C'est l'initrd qui va râler
s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais je ne crois pas que ce suport doit être dans l'initrd ou qu'il faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas confondre l'UUID d'une partition (défini dans la table de partition du disque) avec l'UUID du système de fichiers qu'elle contient (dans les méta-données du système de fichiers), qu'on utilise avec root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques partitionnés au format GPT mais pas avec les disques partitionnés au format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis la version 3.2 le noyau peut construire des UUID de partitions pour les disques au format MS-DOS à partir de l'identifiant unique (signature) du disque stocké dans le MBR et du numéro de la partition, par exemple 0002dd75-01 pour la première partition si 0002dd75 est la signature du disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la version 3.2, on peut spécifier un offset pour désigner la racine avec la syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée. Je ne sait pas comment désactiver ceci sous Debian. Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé le noyau est content car il a une racine. C'est l'initrd qui va râler s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Pim
Le Sat, 21 Feb 2015 10:55:17 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Pascal Hambourg disait ceci :
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais je ne crois pas que ce suport doit être dans l'initrd ou qu'il faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas confondre l'UUID d'une partition (défini dans la table de partition du disque) avec l'UUID du système de fichiers qu'elle contient (dans les méta-données du système de fichiers), qu'on utilise avec root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques partitionnés au format GPT mais pas avec les disques partitionnés au format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis la version 3.2 le noyau peut construire des UUID de partitions pour les disques au format MS-DOS à partir de l'identifiant unique (signature) du disque stocké dans le MBR et du numéro de la partition, par exemple 0002dd75-01 pour la première partition si 0002dd75 est la signature du disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la version 3.2, on peut spécifier un offset pour désigner la racine avec la syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée. Je ne sait pas comment désactiver ceci sous Debian. Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé le noyau est content car il a une racine. C'est l'initrd qui va râler s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Bonjour Pascal.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas. Et grub2 peut très bien charger n'importe quel module sans initrd. D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que j'ai avancé puisque désormais mon kernel boot sans l'initrd mais avec le disque racine root=/dev/sdb5, mais je souhaiterai pouvoir comme avec l'encien noyau qu'il démare avec root=UUID=xxxxxx car j'ai un multiboot et je souhaite pouvoir changer mes disques de controleur bien que ceci n'arrive pas tous les jours. Par contre je ne suis pas certain de t'avoir compris :
Le dernier noyaux que j'ai booté sans initrd et qui reconnaissait bien l'uuid de ma partition racine tout juste antérieur à la version que tu cites.
Si j'ai bien compris root=UUID=xxxxxx dans la config de grub n'est plus valide ou il faut en plus préciser l'UUID de partition dans grub? Comprend pas bien.
Peut-tu préciser si tu en sait plus sur ce point?
D'avance Merci.
Bien Cordialement.
Le Sat, 21 Feb 2015 10:55:17 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement
récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais
je ne crois pas que ce suport doit être dans l'initrd ou qu'il
faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du
support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la
syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas
confondre l'UUID d'une partition (défini dans la table de partition du
disque) avec l'UUID du système de fichiers qu'elle contient (dans les
méta-données du système de fichiers), qu'on utilise avec
root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques
partitionnés au format GPT mais pas avec les disques partitionnés au
format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis
la version 3.2 le noyau peut construire des UUID de partitions pour les
disques au format MS-DOS à partir de l'identifiant unique (signature) du
disque stocké dans le MBR et du numéro de la partition, par exemple
0002dd75-01 pour la première partition si 0002dd75 est la signature du
disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la
version 3.2, on peut spécifier un offset pour désigner la racine avec la
syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la
n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas
avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée.
Je ne sait pas comment désactiver ceci sous Debian.
Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien
sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé
le noyau est content car il a une racine. C'est l'initrd qui va râler
s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Bonjour Pascal.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas.
Et grub2 peut très bien charger n'importe quel module sans initrd.
D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que
j'ai avancé puisque désormais mon kernel boot sans l'initrd
mais avec le disque racine root=/dev/sdb5, mais je souhaiterai
pouvoir comme avec l'encien noyau qu'il démare avec
root=UUID=xxxxxx car j'ai un multiboot et je souhaite pouvoir changer mes
disques de controleur bien que ceci n'arrive pas tous les jours.
Par contre je ne suis pas certain de t'avoir compris :
Le dernier noyaux que j'ai booté sans initrd et qui
reconnaissait bien l'uuid de ma partition racine
tout juste antérieur à la version que tu cites.
Si j'ai bien compris root=UUID=xxxxxx dans la config
de grub n'est plus valide ou il faut en plus préciser
l'UUID de partition dans grub? Comprend pas bien.
Le Sat, 21 Feb 2015 10:55:17 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Pascal Hambourg disait ceci :
Ce n'est pas un régression, ça a toujours été ainsi : sauf changement récent, le noyau ne gère pas les UUID.
Tu ne m'as pas compris, mais peut-être aussi que je n'ai pas été très clair:
Je pense que si.
Moi je suis POUR l'UUID pour la reconnaissance des disques mais je ne crois pas que ce suport doit être dans l'initrd ou qu'il faille une initrd pour cela.
J'ai cherché dans le changements du noyau, et pas trouvé d'ajout du support des UUID de système de fichiers dans le noyau pour la racine.
Par contre j'ai découvert le support des UUID de partition avec la syntaxe root=PARTUUID=<part_uuid> depuis la version 2.6.37. Ne pas confondre l'UUID d'une partition (défini dans la table de partition du disque) avec l'UUID du système de fichiers qu'elle contient (dans les méta-données du système de fichiers), qu'on utilise avec root=UUID=<fs_uuid>. C'était initialement utilisable avec les disques partitionnés au format GPT mais pas avec les disques partitionnés au format MS-DOS du MBR qui ne définit pas d'UUID de partition, mais depuis la version 3.2 le noyau peut construire des UUID de partitions pour les disques au format MS-DOS à partir de l'identifiant unique (signature) du disque stocké dans le MBR et du numéro de la partition, par exemple 0002dd75-01 pour la première partition si 0002dd75 est la signature du disque.
Autre fonctionnalité plus anecdotique que j'ai découverte : depuis la version 3.2, on peut spécifier un offset pour désigner la racine avec la syntaxe root=PARTUUID=<part_uuid>/PARTNROFF=<n>, ce qui désigne la n-ième partition après celle qui a l'UUID indiqué.
En tout cas j'ai enfin réussit à booter mais avec root=/dev/sda5, mais pas avec l'UUID.
Une initrd a été générée alors qu'elle n'étais pas demandée. Je ne sait pas comment désactiver ceci sous Debian. Le fait que je dise ou pas (à grub) de charger l'initrd ne change rien sur ce point. Voila.
Il y a quoi dans cet initrd ? Normalement si un initrd valide est chargé le noyau est content car il a une racine. C'est l'initrd qui va râler s'il ne trouve pas la racine finale, mais ça ne produit pas un kernel panic.
Bonjour Pascal.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas. Et grub2 peut très bien charger n'importe quel module sans initrd. D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que j'ai avancé puisque désormais mon kernel boot sans l'initrd mais avec le disque racine root=/dev/sdb5, mais je souhaiterai pouvoir comme avec l'encien noyau qu'il démare avec root=UUID=xxxxxx car j'ai un multiboot et je souhaite pouvoir changer mes disques de controleur bien que ceci n'arrive pas tous les jours. Par contre je ne suis pas certain de t'avoir compris :
Le dernier noyaux que j'ai booté sans initrd et qui reconnaissait bien l'uuid de ma partition racine tout juste antérieur à la version que tu cites.
Si j'ai bien compris root=UUID=xxxxxx dans la config de grub n'est plus valide ou il faut en plus préciser l'UUID de partition dans grub? Comprend pas bien.
Peut-tu préciser si tu en sait plus sur ce point?
D'avance Merci.
Bien Cordialement.
Pim
Le 20 Feb 2015 23:06:11 GMT, Nicolas George <nicolas$ disait ceci :
Pim , dans le message , a écrit :
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire
Ah ?
Quoi Ah? Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Non en fait : tu as aussi le boot-loader, mais tout ceci n'a rien à voir avec l'initrd. L'inird ne contient que des modules, donc des briques de codes du noyau.
Du reste avec grub 2 ces modules peuvent aussi être placé dans grub afin d'être chargés au plus tôt par grub2.
Me trompe-je?
Merci en tout cas?
Le 20 Feb 2015 23:06:11 GMT,
Nicolas George <nicolas$george@salle-s.org> disait ceci :
Pim , dans le message <slrnmeffg2.8kj.moi@Amd64.Mydomain.net>, a écrit :
Après pour reconnaitre une partition racine en uuid, seul le
noyau peut le faire
Ah ?
Quoi Ah?
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de
ta partition racine, non?
Après une fois démarré, il y a peut-être d'autres façons de la faire
mais quand tu démarres, tu n'as que le noyau.
Non en fait : tu as aussi le boot-loader, mais tout ceci
n'a rien à voir avec l'initrd. L'inird ne contient que
des modules, donc des briques de codes du noyau.
Du reste avec grub 2 ces modules peuvent aussi être
placé dans grub afin d'être chargés au plus tôt par grub2.
Le 20 Feb 2015 23:06:11 GMT, Nicolas George <nicolas$ disait ceci :
Pim , dans le message , a écrit :
Après pour reconnaitre une partition racine en uuid, seul le noyau peut le faire
Ah ?
Quoi Ah? Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Non en fait : tu as aussi le boot-loader, mais tout ceci n'a rien à voir avec l'initrd. L'inird ne contient que des modules, donc des briques de codes du noyau.
Du reste avec grub 2 ces modules peuvent aussi être placé dans grub afin d'être chargés au plus tôt par grub2.
Me trompe-je?
Merci en tout cas?
Nicolas George
Pim , dans le message , a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que des modules
Non.
Pim , dans le message <slrnmemc9d.2cd.moi@Amd64.Mydomain.net>, a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de
ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire
mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que
des modules
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que des modules
Non.
Pim
Le 23 Feb 2015 14:49:42 GMT, Nicolas George <nicolas$ disait ceci :
Pim , dans le message , a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que des modules
Non.
Non c'est vrai : c'est une arborescence ou si on veut une root avec un /bin qui contient quelques utilitaires dont blkid qui retrouve la "vraie" partition au moyen de l'UUID.
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Merci pour ta patience.
Pim.
Le 23 Feb 2015 14:49:42 GMT,
Nicolas George <nicolas$george@salle-s.org> disait ceci :
Pim , dans le message <slrnmemc9d.2cd.moi@Amd64.Mydomain.net>, a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de
ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire
mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que
des modules
Non.
Non c'est vrai : c'est une arborescence ou si on veut
une root avec un /bin qui contient quelques utilitaires
dont blkid qui retrouve la "vraie" partition
au moyen de l'UUID.
Bon et comment se fait-til que je démarre sans initrd
et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Le 23 Feb 2015 14:49:42 GMT, Nicolas George <nicolas$ disait ceci :
Pim , dans le message , a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
Non, c'est juste un lien symbolique.
Après une fois démarré, il y a peut-être d'autres façons de la faire mais quand tu démarres, tu n'as que le noyau.
Il y a aussi l'initrd, justement.
n'a rien à voir avec l'initrd. L'inird ne contient que des modules
Non.
Non c'est vrai : c'est une arborescence ou si on veut une root avec un /bin qui contient quelques utilitaires dont blkid qui retrouve la "vraie" partition au moyen de l'UUID.
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Merci pour ta patience.
Pim.
Nicolas George
Pim , dans le message , a écrit :
n'a rien à voir avec l'initrd. L'inird ne contient que des modules
Non c'est vrai : c'est une arborescence ou si on veut une root avec un /bin qui contient quelques utilitaires dont blkid
« Quelques utilitaires » et « que des modules » : tu te contredis toi-même.
Pim , dans le message <slrnmenal8.74m.moi@Amd64.Mydomain.net>, a écrit :
n'a rien à voir avec l'initrd. L'inird ne contient que
des modules
Non c'est vrai : c'est une arborescence ou si on veut
une root avec un /bin qui contient quelques utilitaires
dont blkid
« Quelques utilitaires » et « que des modules » : tu te contredis toi-même.
