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.
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.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas.
Tu n'as pas le choix si tu veux désigner la racine par son UUID de système de fichiers.
Et grub2 peut très bien charger n'importe quel module sans initrd.
GRUB ne s'occupe en rien des modules du noyau, si c'est de cela que tu parles. Il charge l'image du noyau, optionnellement l'initramfs, passe la main au noyau et son rôle s'arrête là.
D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que
J'ai vu.
j'ai avancé puisque désormais mon kernel boot sans l'initrd mais avec le disque racine root=/dev/sdb5, mais je souhaiterai
Voilà. Sans initramfs mais sans UUID.
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.
Alors il te faut un initramfs.
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.
Au risque de me répéter : à ma connaissance ce n'est pas possible, ça n'a jamais été possible. Tu penses bien que si une telle fonctionnalité (que je n'ai pas trouvée) avait été ajouté au noyau, elle n'aurait pas été retirée du jour au lendemain. Néanmoins tu peux comparer les .config des deux noyaux pour voir si une option relative aux UUID n'aurait pas été désactivée dans celui du plus récent.
A noter, c'est peut-être peu connu, que l'initramfs n'est pas forcément un fichier séparé mais peut être inclus dans l'image du noyau à la construction de celui-ci, en le spécifiant dans l'option CONFIG_INITRAMFS_SOURCE.
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.
root=UUID=<fs_uuid> est encore valide mais uniquement utilisable avec un initramfs.
root=PARTUUID=<part_uuid> est utilisable directement par le noyau sans initramfs s'il peut associer un UUID à la partition, donc notamment avec un disque au format GPT si noyau > 2.6.37 ou un disque au format MBR avec noyau >= 3.8 (et non 3.2 contrairement à ce que j'ai écrit dans mon message précédent).
En tout cas c'est l'un ou l'autre, pas les deux en même temps.
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.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas.
Tu n'as pas le choix si tu veux désigner la racine par son UUID de
système de fichiers.
Et grub2 peut très bien charger n'importe quel module sans initrd.
GRUB ne s'occupe en rien des modules du noyau, si c'est de cela que tu
parles. Il charge l'image du noyau, optionnellement l'initramfs, passe
la main au noyau et son rôle s'arrête là.
D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que
J'ai vu.
j'ai avancé puisque désormais mon kernel boot sans l'initrd
mais avec le disque racine root=/dev/sdb5, mais je souhaiterai
Voilà. Sans initramfs mais sans UUID.
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.
Alors il te faut un initramfs.
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.
Au risque de me répéter : à ma connaissance ce n'est pas possible, ça
n'a jamais été possible. Tu penses bien que si une telle fonctionnalité
(que je n'ai pas trouvée) avait été ajouté au noyau, elle n'aurait pas
été retirée du jour au lendemain. Néanmoins tu peux comparer les .config
des deux noyaux pour voir si une option relative aux UUID n'aurait pas
été désactivée dans celui du plus récent.
A noter, c'est peut-être peu connu, que l'initramfs n'est pas forcément
un fichier séparé mais peut être inclus dans l'image du noyau à la
construction de celui-ci, en le spécifiant dans l'option
CONFIG_INITRAMFS_SOURCE.
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.
root=UUID=<fs_uuid> est encore valide mais uniquement utilisable avec un
initramfs.
root=PARTUUID=<part_uuid> est utilisable directement par le noyau sans
initramfs s'il peut associer un UUID à la partition, donc notamment avec
un disque au format GPT si noyau > 2.6.37 ou un disque au format MBR
avec noyau >= 3.8 (et non 3.2 contrairement à ce que j'ai écrit dans mon
message précédent).
En tout cas c'est l'un ou l'autre, pas les deux en même temps.
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.
Je m'en fou de ce qu'il y a dans l'initrd puisque je n'en veux pas.
Tu n'as pas le choix si tu veux désigner la racine par son UUID de système de fichiers.
Et grub2 peut très bien charger n'importe quel module sans initrd.
GRUB ne s'occupe en rien des modules du noyau, si c'est de cela que tu parles. Il charge l'image du noyau, optionnellement l'initramfs, passe la main au noyau et son rôle s'arrête là.
D'ailleurs maintenant, je te rappel au cas ou tu n'aurais pas suivi que
J'ai vu.
j'ai avancé puisque désormais mon kernel boot sans l'initrd mais avec le disque racine root=/dev/sdb5, mais je souhaiterai
Voilà. Sans initramfs mais sans UUID.
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.
Alors il te faut un initramfs.
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.
Au risque de me répéter : à ma connaissance ce n'est pas possible, ça n'a jamais été possible. Tu penses bien que si une telle fonctionnalité (que je n'ai pas trouvée) avait été ajouté au noyau, elle n'aurait pas été retirée du jour au lendemain. Néanmoins tu peux comparer les .config des deux noyaux pour voir si une option relative aux UUID n'aurait pas été désactivée dans celui du plus récent.
A noter, c'est peut-être peu connu, que l'initramfs n'est pas forcément un fichier séparé mais peut être inclus dans l'image du noyau à la construction de celui-ci, en le spécifiant dans l'option CONFIG_INITRAMFS_SOURCE.
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.
root=UUID=<fs_uuid> est encore valide mais uniquement utilisable avec un initramfs.
root=PARTUUID=<part_uuid> est utilisable directement par le noyau sans initramfs s'il peut associer un UUID à la partition, donc notamment avec un disque au format GPT si noyau > 2.6.37 ou un disque au format MBR avec noyau >= 3.8 (et non 3.2 contrairement à ce que j'ai écrit dans mon message précédent).
En tout cas c'est l'un ou l'autre, pas les deux en même temps.
Pascal Hambourg
Pascal Hambourg a écrit :
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
Correction : depuis la version 3.8.
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.
Pascal Hambourg a écrit :
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
Correction : depuis la version 3.8.
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.
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
Correction : depuis la version 3.8.
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.
Pascal Hambourg
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd
et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Pascal Hambourg
Pim a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
/dev ne peut exister que lorsque la racine est montée.
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.
Donc pas encore de racine, donc pas de /dev.
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.
Non, l'initramfs contient au moins un exécutable /init, et optionnellement des modules du noyau, des programmes userland (typiquement udev, mdadm, lvm, busybox...), bibliothèques, fichiers de configuration...
Du reste avec grub 2 ces modules peuvent aussi être placé dans grub afin d'être chargés au plus tôt par grub2.
Les modules du noyau ? Non, en aucun cas ils ne peuvent être chargés par GRUB. GRUB ne peut charger que ses propres modules qui n'ont rien à voir avec les modules du noyau.
Pim a écrit :
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de
ta partition racine, non?
/dev ne peut exister que lorsque la racine est montée.
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.
Donc pas encore de racine, donc pas de /dev.
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.
Non, l'initramfs contient au moins un exécutable /init, et
optionnellement des modules du noyau, des programmes userland
(typiquement udev, mdadm, lvm, busybox...), bibliothèques, fichiers de
configuration...
Du reste avec grub 2 ces modules peuvent aussi être
placé dans grub afin d'être chargés au plus tôt par grub2.
Les modules du noyau ? Non, en aucun cas ils ne peuvent être chargés par
GRUB. GRUB ne peut charger que ses propres modules qui n'ont rien à voir
avec les modules du noyau.
Quand tu démarres c'est /dev/disks/by-uuid qui te donne l'UUID de ta partition racine, non?
/dev ne peut exister que lorsque la racine est montée.
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.
Donc pas encore de racine, donc pas de /dev.
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.
Non, l'initramfs contient au moins un exécutable /init, et optionnellement des modules du noyau, des programmes userland (typiquement udev, mdadm, lvm, busybox...), bibliothèques, fichiers de configuration...
Du reste avec grub 2 ces modules peuvent aussi être placé dans grub afin d'être chargés au plus tôt par grub2.
Les modules du noyau ? Non, en aucun cas ils ne peuvent être chargés par GRUB. GRUB ne peut charger que ses propres modules qui n'ont rien à voir avec les modules du noyau.
Pim
Le Wed, 25 Feb 2015 09:51:09 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise: J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi, c'est probablement moi qui ai écrit les UUID sur tous les kernel, mais seul ceux avec initrd devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd, mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Comment dire que ce sujet est résolu?
Merci à vous tous pour votre aide.
Le Wed, 25 Feb 2015 09:51:09 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd
et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise:
J'ai du 1 seule fois dans ma vie , démonter une initrd
pour voir comment c'est fait dedans, et pour
ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi,
c'est probablement moi qui ai écrit les UUID sur
tous les kernel, mais seul ceux avec initrd
devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd,
mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque
mon dernier noyau fraichement compilé démarre
avec /dev/sdxx sans problème.
Le Wed, 25 Feb 2015 09:51:09 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise: J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi, c'est probablement moi qui ai écrit les UUID sur tous les kernel, mais seul ceux avec initrd devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd, mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Comment dire que ce sujet est résolu?
Merci à vous tous pour votre aide.
Doug713705
Le 27-02-2015, Pim nous expliquait dans fr.comp.os.linux.configuration () :
Le Wed, 25 Feb 2015 09:51:09 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise: J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi, c'est probablement moi qui ai écrit les UUID sur tous les kernel, mais seul ceux avec initrd devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd, mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Comment dire que ce sujet est résolu?
Soit en laissant couler la discussion soit, pour plus de visibilité mais sans obligation placer une balise dans le sujet ex:
[RESOLU] Boot sur UUID sans initrd (était: Forum specifique au noyaux Linux?)
-- Moi je vous dis bravo et vive la mort ! -- H.F. Thiéfaine, Aligator 427
Le 27-02-2015, Pim nous expliquait dans
fr.comp.os.linux.configuration
(<slrnmf0en8.2pb.moi@Amd64.Mydomain.net>) :
Le Wed, 25 Feb 2015 09:51:09 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd
et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise:
J'ai du 1 seule fois dans ma vie , démonter une initrd
pour voir comment c'est fait dedans, et pour
ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi,
c'est probablement moi qui ai écrit les UUID sur
tous les kernel, mais seul ceux avec initrd
devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd,
mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque
mon dernier noyau fraichement compilé démarre
avec /dev/sdxx sans problème.
Comment dire que ce sujet est résolu?
Soit en laissant couler la discussion soit, pour plus de visibilité mais
sans obligation placer une balise dans le sujet
ex:
[RESOLU] Boot sur UUID sans initrd (était: Forum specifique au noyaux Linux?)
--
Moi je vous dis bravo et vive la mort !
-- H.F. Thiéfaine, Aligator 427
Le 27-02-2015, Pim nous expliquait dans fr.comp.os.linux.configuration () :
Le Wed, 25 Feb 2015 09:51:09 +0100, Pascal Hambourg disait ceci :
Pim a écrit :
Bon et comment se fait-til que je démarre sans initrd et avec l'UUID avec un vieux kernel : 2.6.33.7 ?
Il y a forcément un initramfs. D'où vient ce noyau ?
Heu oui : autant pour moi.
Et je ne contredis pas le fait que je me contredise: J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
En fait le vieux menu.cfg n'as peut-être jamais bouté ainsi, c'est probablement moi qui ai écrit les UUID sur tous les kernel, mais seul ceux avec initrd devait démarrer de la sorte.
Bon je vais essayer le vieux kernel avec l'initrd, mais je ne pense pas qu'il puisse démarrer ainsi.
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Comment dire que ce sujet est résolu?
Soit en laissant couler la discussion soit, pour plus de visibilité mais sans obligation placer une balise dans le sujet ex:
[RESOLU] Boot sur UUID sans initrd (était: Forum specifique au noyaux Linux?)
-- Moi je vous dis bravo et vive la mort ! -- H.F. Thiéfaine, Aligator 427
Pascal Hambourg
Pim a écrit :
J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
Je peux comprendre, ayant moi-même été réticent à l'utilisation d'initrd puis initramfs au début. Et puis avec l'expérience j'ai appris à les apprécier. Ainsi combien de fois en ajoutant un disque PATA dans une machine, le disque SATA d'origine est-il passé de sda à sdb sans que cela gêne puisque la racine, les autres systèmes de fichiers et le swap étaient identifiés par leur UUID ?
Avec la couche d'abstraction qui émule tous les supports de stockage de masse courants (PATA, SATA, USB...) comme des disques SCSI, on ne peut plus se fier au nommage traditionnel des disques dès qu'il en a plusieurs. Même s'il n'y a qu'un seul disque fixe, la clé USB qu'on a laissé branchée peut prendre son nom au prochain redémarrage et tout perturber.
Il y a également des cas où l'initramfs est indispensable car l'activation de la racine nécessite l'intervention de programmes userland, notamment : - racine chiffrée - racine sur LVM - racine sur RAID logiciel (sauf si se limite aux vieux format 0.90 autodetect qui a des inconvénients par rapport au format par défaut actuel 1.2)
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Si le disque est au format GPT, avec ton noyau 3.2.x tu pourrais spécifier la racine par son UUID de partition (root=PARTUUID=xxx) comme je l'ai mentionné plus haut dans ce fil. GPT c'est bon, mangez-en. Ce n'est pas réservé aux systèmes modernes à UEFI ni aux disques de plus de 2 Tio, ça marche aussi avec les vieilles machines.
Pim a écrit :
J'ai du 1 seule fois dans ma vie , démonter une initrd
pour voir comment c'est fait dedans, et pour
ma part, je préfère démarrer sans.
Je peux comprendre, ayant moi-même été réticent à l'utilisation d'initrd
puis initramfs au début. Et puis avec l'expérience j'ai appris à les
apprécier. Ainsi combien de fois en ajoutant un disque PATA dans une
machine, le disque SATA d'origine est-il passé de sda à sdb sans que
cela gêne puisque la racine, les autres systèmes de fichiers et le swap
étaient identifiés par leur UUID ?
Avec la couche d'abstraction qui émule tous les supports de stockage de
masse courants (PATA, SATA, USB...) comme des disques SCSI, on ne peut
plus se fier au nommage traditionnel des disques dès qu'il en a
plusieurs. Même s'il n'y a qu'un seul disque fixe, la clé USB qu'on a
laissé branchée peut prendre son nom au prochain redémarrage et tout
perturber.
Il y a également des cas où l'initramfs est indispensable car
l'activation de la racine nécessite l'intervention de programmes
userland, notamment :
- racine chiffrée
- racine sur LVM
- racine sur RAID logiciel (sauf si se limite aux vieux format 0.90
autodetect qui a des inconvénients par rapport au format par défaut
actuel 1.2)
Dans ce cas il n'y a rien d'autre à voir, puisque
mon dernier noyau fraichement compilé démarre
avec /dev/sdxx sans problème.
Si le disque est au format GPT, avec ton noyau 3.2.x tu pourrais
spécifier la racine par son UUID de partition (root=PARTUUID=xxx) comme
je l'ai mentionné plus haut dans ce fil. GPT c'est bon, mangez-en. Ce
n'est pas réservé aux systèmes modernes à UEFI ni aux disques de plus de
2 Tio, ça marche aussi avec les vieilles machines.
J'ai du 1 seule fois dans ma vie , démonter une initrd pour voir comment c'est fait dedans, et pour ma part, je préfère démarrer sans.
Je peux comprendre, ayant moi-même été réticent à l'utilisation d'initrd puis initramfs au début. Et puis avec l'expérience j'ai appris à les apprécier. Ainsi combien de fois en ajoutant un disque PATA dans une machine, le disque SATA d'origine est-il passé de sda à sdb sans que cela gêne puisque la racine, les autres systèmes de fichiers et le swap étaient identifiés par leur UUID ?
Avec la couche d'abstraction qui émule tous les supports de stockage de masse courants (PATA, SATA, USB...) comme des disques SCSI, on ne peut plus se fier au nommage traditionnel des disques dès qu'il en a plusieurs. Même s'il n'y a qu'un seul disque fixe, la clé USB qu'on a laissé branchée peut prendre son nom au prochain redémarrage et tout perturber.
Il y a également des cas où l'initramfs est indispensable car l'activation de la racine nécessite l'intervention de programmes userland, notamment : - racine chiffrée - racine sur LVM - racine sur RAID logiciel (sauf si se limite aux vieux format 0.90 autodetect qui a des inconvénients par rapport au format par défaut actuel 1.2)
Dans ce cas il n'y a rien d'autre à voir, puisque mon dernier noyau fraichement compilé démarre avec /dev/sdxx sans problème.
Si le disque est au format GPT, avec ton noyau 3.2.x tu pourrais spécifier la racine par son UUID de partition (root=PARTUUID=xxx) comme je l'ai mentionné plus haut dans ce fil. GPT c'est bon, mangez-en. Ce n'est pas réservé aux systèmes modernes à UEFI ni aux disques de plus de 2 Tio, ça marche aussi avec les vieilles machines.
