Bonjour Nal<
Tu voudra bien m'excuser pour ce journal ayant un intérêt tout relatif, pour ne pas dire bien faible, mais une de mes "marottes" c'est le boot.
Qui ne s'est jamais amusé à se faire ses propres initramfs ? Qui ne s'est jamais amusé à coller tout son système dans un initramfs ? Qui ne s'est jamais amusé à compiler un noyau monolithique / sans module / tout en dur juste pour sa machine sans rien d'autre ? Trois choses bien différentes, seulement liées par l'amusement avec son pc, et à l'initrd. Ces amusements ont leurs jours compté aujourd'hui, car « initrd is dying ».
Sur Fedora (arch aussi ??) il n'est plus nécessaire. Sans rien d'autre à faire que de commenter la ligne correspondante dans grub. Rien d'autre. Vraiment ? Oui, à certaines conditions : ne pas utiliser LVM (ou chiffrement ou raid logiciel) ne pas utiliser les UUID pour les partitions mais faire appeler la partition root par son nom sdx. Mais encore ? C'est tout.
Exemple de /proc/cmdline :
BOOT_IMAGE=/vmlinuz-4.10.13-200.fc25.x86_64 root=/dev/sda3 rootfstype=ext4 ro pcie_aspm=off elevator=deadline rhgb LANG=fr_FR.UTF-8 vt.global_cursor_default=0 rd.udev.log-priority=0 quiet rd.systemd.show_status=false
- root= non pas un uuid mais simplement son nom en sdx
- rootfstype = pour lui dire qu'il s'agit de ce fs (remplace par le tiens, xfs, ext3, f2fs? … que sais je)
- quiet (suivi de) rd.systemd.show_status = j'aime pas voir ces logs
- vt.global_cursor_default = j'aime pas voir un curseur qui clignote tout seul en haut Ă gauche de l'Ă©cran pendant le boot, quant aucune log ne s'affichent au boot.
Et bien sûr un timeout=0 pour grub, j'aime pas voir grub. Enfin, il suffit de commenter la ligne "initrd" (ou initrdefi) dans la configuration de grub.
Rebootez, et voilà vous avez tout cassé. Ou pas.
# .
Posté par Sufflope (site web personnel) . Évalué à  8.
Beurk.
[^] # Re: .
Posté par Octabrain . Évalué à  10.
Ouais, du coup initrd n'est pas dying du tout, merci pour le titre putaclick…
[^] # Re: .
Posté par Sébastien Koechlin . Évalué à  8.
Pareil, je ne vois pas trop l'intérêt de se passer de LVM.
Choisir entre
- un système qui impose des partitions fixées en taille et en position à l’installation du disque; et
- un système qui permet d'agrandir, réduire, déplacer vers un autre disque, faire des snapshots, installer plusieurs distributions et plusieurs versions pour un coût négligeable,
ça fait longtemps que j'ai choisi.
[^] # Re: .
Posté par Marotte ⛧ . Évalué à  6.
Quand je repense au temps qu’on passait à définir le partionnement avant LVM…
Maintenant je mets je le minimum partout et je garde de l’espace LVM libre pour agrandir là où ça va coincer.
Même pour une seule distribution et sans même considérer la possibilité de faire des snapshots, c’est infiniment plus pratique avec LVM.
Longue vie à initrd !
[^] # Re: .
Posté par Anonyme . Évalué à  3. Dernière modification le 04 mai 2017 à 12:57.
LVM perd grandement de son intérêt avec une mono-partition ou je me trompe ?
Ça fait des années que je ne fais plus de partition séparées (ni sur serveur/VM, ni sur destkop/laptop), j’ai du mal à voir l’avantage de LVM.
[^] # Re: .
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à  5.
La possibilité de changer de disque dur en continuant à utiliser la machine, c'est pas mal comme fonctionnalité par exemple.
[^] # Re: .
Posté par barmic . Évalué à  2.
Pour changer de disque, sur machine personnelle alors… :
Le tout pour gagner le temps de la copie soit quelques dizaines de minutes chez moi \o/
Sur serveur, je préfère amplement investir du temps dans un gestionnaire de conf et des backups, ça couvre un champ bien plus vaste d'usages. Si tu ne t'autorise pas à avoir 1h d'indisponibilité c'est que tu as redondé ton système sur 2 machines.
Donc oui c'est joli comme fonctionnalité, mais l'utilité est plus faible que ce que l'esthétisme technique ne le fait croire.
La gestion de volume garde beaucoup d'intérêt pour avoir des volumes qui soient plus grands que la taille des disques et pour faire des snaphsots.
Tous les contenus que j'Ă©cris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes Ă©crits)
[^] # Re: .
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à  4.
Pas tout à fait, l'opération de déplacement des données par LVM est plus simple que de formater et de rsyncer ou autre.
[^] # Re: .
Posté par barmic . Évalué à  3.
Oui mais tu dois de toute manière pouvoir gérer l'autre et la tester le plus régulièrement possible.
Pour gérer des SLA (Service-level agreement), il y a d'autres techniques plus puissantes car elles sont capables de continuer à faire vivre les données, même si la machine physique disparaît.
Au final LVM me semble être devenu une petite solution quand on connaît depuis une certain temps et quand on a pas non plus de très grosses contraintes genre SLA.
Tous les contenus que j'Ă©cris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes Ă©crits)
[^] # Re: .
Posté par gouttegd . Évalué à  3.
Un exemple parmi d’autres : je monte une machine avec un disque dur initial de 300 Gio, au bout de quelques années d’utilisation je m’aperçois que la place commence à me manquer (j’utilise cette machine notamment comme système de stockage), j’achète un nouveau disque de 1 Tio que j’installe dans la machine (à côté du premier disque) et j’étends mon volume logique sur le nouveau disque. Temps total passé à la manœuvre : 5 minutes (arrêter la machine, ouvrir le boîtier, brancher le disque, redémarrer, saisir les trois commandes appropriées pour ajouter le nouveau disque au groupe de volumes et étendre le volume logique).
[^] # Re: .
Posté par gouttegd . Évalué à  4.
Et au bout d’encore quelques années : zut je vais de nouveau bientôt être à l’étroit, et en plus je ne peux brancher que deux disques sur cette machine, mais que faire ?
J’achète un nouveau disque de 2 Tio, je m’assure (avec pvmove) que toutes les données de mon volume logique sont sur le second disque (celui de 1 Tio), j’enlève le premier disque (désormais vide, donc) et je le remplace par le nouveau, sur lequel j’étends à nouveau le volume logique…
[^] # Re: .
Posté par Moonz . Évalué à  6.
Tu peux aussi faire une seule partition, c’est encore plus simple.
[^] # Re: .
Posté par totof2000 . Évalué à  -3.
Non.
# Mouais
Posté par Christophe . Évalué à  10.
En gros, si on n'utilise pas ce qui fait l'utilité d'un initrd, alors on peut s'en passer. Oui enfin bon, comment dire, forcément !
# internet of things
Posté par goeb . Évalué à  1.
Sur le desktop, peut-ĂŞtre.
Mais dans les objets connectés, tels que caméra wifi, ou répéteur wifi, etc. ? initrd n'est-il pas utile pour eux ?
[^] # Re: internet of things
Posté par Renault (site web personnel) . Évalué à  4.
En quoi ?
Il devient rare d'utiliser l'initramfs dans les systèmes embarqué, cela manque de souplesse quand même.
Personnellement mes derniers projets n'en ont plus.
[^] # Re: internet of things
Posté par Christophe . Évalué à  3.
Faudra dire ça aux développeurs d'Android, je crois qu'ils ne sont pas au courant :)
[^] # Re: internet of things
Posté par Anthony Jaguenaud . Évalué à  7.
Peut-on vraiment considérer comme de l’embarqué un téléphone android qui a 2Go de RAM 8Go de flash + une carte SD ? ;-)
Sinon, pour l’initrd, tant que tout est dans le noyau, ce n’est pas nécessaire, mais dès qu’il faut intégrer des trucs en dehors ou pour plus de souplesse le mécanisme reste indispensable.
[^] # Re: internet of things
Posté par dyno partouzeur du centre . Évalué à  7.
Non, quand tu es sur un système embarqué, tu as tout intérêt à avoir un kernel monolithique taillé sur mesure avec juste ce dont tu as besoin. Tu gagneras en espace de stockage utilisé, en RAM et en temps de boot.
# RĂ©cent '
Posté par claudex . Évalué à  7.
J'ai l'impression que je m'étais déjà amusé à faire ça il y a des années (mais peut-être que ma mémoire me joue des tours). Il y a quelque chose qui a changé à ce niveau récemment ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RĂ©cent '
Posté par galactikboulay . Évalué à  7.
Non absolument pas, à partir du moment où les drivers nécessaires (notamment disque et filesystems) sont compilés dans le noyau, il n'y a aucune raison que ça ne marche pas.
Le journal ne présente aucun intérêt en tant que tel :)
[^] # Re: RĂ©cent '
Posté par Thomas Debesse (site web personnel) . Évalué à  4.
Tu as tout à fait raison, d’ailleurs pour moi ce n’était pas “juste pour voir”, c’était le comportement par défaut des mes Slackware autour de 2005 par là , et ce n’étais pas par volonté de ne pas mettre d’initrd, il n’y en avait tout simplement pas besoin, je ne savais même pas ce qu’était un initrd parce que je n’en avais pas besoin. Je compilais mon noyau avec le nécessaire en dur et seulement les pilotes audio en module (parce les pilotes alsa n’aimaient pas être en dur, je ne sais pas trop pourquoi mais c’était un constat), et je mettais une ligne dans le grub et voilà . C’est quand je suis passé à des systèmes plus grand public comme ubuntu (qui te mettent des animations de démarrage et tout) que j’ai vu arriver sur ma machine le premier initrd de ma vie. Je ne pense pas que l’initird ait été une nécessité à un moment, c’est juste que c’est bien plus pratique à cette étape du boot d’avoir plus de fonctionnalités que le noyau seul ne peut fournir…
Accessoirement, la seule fois de ma vie où j’ai eu à personnaliser un initrd était pour un disque de boot chiffré, c’était un disque dur en usb connecté sur un port usb 2.0 pcmcia, et il fallait ajouter les module pcmcia à l’initrd. Bon le truc un peu cowboy c’est que le BIOS ne savait pas booter sur le disque usb 2.0 via la carte pcmcia mais uniquement sur les ports usb 1.0 intégrés, donc l’astuce c’était de brancher le disque sur le port usb 1.0 pour que le bios charge grub, et une fois que grub était chargé, grub chargeait le noyeau et l’initrd, et une fois tout à chargé, il suffisait de débrancher le disque usb depuis le port usb 1.0 pour rebrancher le disque sur le port usb 2.0 avant qu’il n’arrive à l’étape du remontage de / en écriture (aujourdghui avec systemd l’init attendrait tranquillement que le disque revienne).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: RĂ©cent '
Posté par Anthony Jaguenaud . Évalué à  4.
J’ai déjà utilisé l’initrd pour pouvoir démarrer une carte sur le « disque » racine dont le driver était un
blobmodule non compilable.Dans ce cas, tu charges le noyau et l’initrd, tu charges le module pour ton disque, puis tu lances un pivot root pour basculer sur ton vrai disque.
# Rien de nouveau ....
Posté par totof2000 . Évalué à  5.
On s'est toujourspassé de l'initrd dans ce cas de figure.
Ce que j'aurais aimé, c'est qu'on puisse se passer de l'initrd en intégrant le nécessaire pour lire une partition LVM root au niveau du noyau. Là ça aurait été intéressant.
# PARTUUID
Posté par Patrick Nicolas . Évalué à  4.
Pourquoi ne pas utiliser un UUID pour root ?
D'après https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/init/do_mounts.c#n183 c'est parfaitement utilisable, avec un PARTUUID.
Le rootfstype n'est pas nécessaire, le kernel trouve bien ce qu'il faut.
Et bonus, avec un EFI on peut mĂŞme se passer de grub.
[^] # Re: PARTUUID
Posté par totof2000 . Évalué à  2.
Euh … Pourquoi ne pas utiliser une IP plutôt qu'un DNS ?
[^] # Re: PARTUUID
Posté par kna . Évalué à  6.
Quand après un reboot ton /dev/sda devient /dev/sde --- ça ne m'est arrivé qu'une fois, et il y a bien longtemps (c'était même /dev/hda en fait) --- tu es bien content de pouvoir utiliser des UUID.
[^] # Re: PARTUUID
Posté par totof2000 . Évalué à  2.
Avec LVM, on s'en fiche …. Il peut passer de /dev/sda à /dev/sdz, tu retrouves tes petits dans ton VG.
[^] # Re: PARTUUID
Posté par Kerro . Évalué à  4.
La notation /dev/sda ne correspond pas au système DNS.
Ce sont plutôt les « labels » qui correspondent au DNS. Et là c'est vrai que c'est nettement plus pratique que les UUID. Par contre les collisions sont possible (par exemple si je nomme toutes mes partitions racines « root », ça coince lorsque je branche un disque venant d'une autre machine). Il faudrait trouver une solution pour cela, et ce serait le système parfait.
[^] # Re: PARTUUID
Posté par Sufflope (site web personnel) . Évalué à  2.
Je note la distinction UUID/label mais tu sembles avoir raté le caractère ironique de totof2000. OK l'analogie n'est pas parfaite mais UUID et label ont la caractéristique d'être décorrélés des réalités physiques, contrairement à /dev/sdXY et l'IP.
Dans une analogie "peut-être déterministe, hors de contrôle" vs. "déterministe configurable", UUID/label sont dans le même sac que DNS, et sdXY/IP dans l'autre.
[^] # Re: PARTUUID
Posté par xcomcmdr . Évalué à  3.
Ça s'appelle les UUID.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: PARTUUID
Posté par Kerro . Évalué à  1.
Ce n'est pas mon ressenti.
Un UUID est juste imbuvable lorsque tu as besoin de sécurité anti-erreur (c'est à dire tout le temps dans mon job), et de ne pas perdre de temps à vérifier qui est quoi (c'est à dire tout le temps aussi). Avec les UUID tu dois vérifier bien attentivement que tu as bien copié/coller le bon. Alors qu'avec un label tu n'as pas ce problème, c'est une source d'erreur de moins.
[^] # Re: PARTUUID
Posté par totof2000 . Évalué à  2.
Je comprends très bien l'intérêt des UUID, qui est de mon point de vue la généralisation d'une solution qui répond à un problème qui est loin d'être courant, tout comme il est parfois utile de passer en dur par des IP plutôt que par des noms DNS. Ce qui me gène avec les UUID, c'est que ce soit généralisé partout (style les mises à jour Ubuntu qui remplacent le nom de mes LV par des UUID dans ma fstab).
[^] # Re: PARTUUID
Posté par gUI (Mastodon) . Évalué à  2.
Quand l'IP est fixe et le DNS variable, oui, je préfère utiliser l'IP :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Modules additionnels
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à  6.
La pertinence de ce journal a déjà été commentée, mais j'en profite pour faire part de quelques idées qui me sont venues dans le passé.
Pour pouvoir démarrer avec un noyau minimaliste qui n'inclut pas les modules qui sont nécessaires pour parvenir à monter le système racine, Linux utilise donc ce système d'initrd, qui consiste à charger en mémoire un système de fichiers initialement monté comme /, qui inclut ces modules, mais aussi un système minimaliste et un script d'init qui charge ces modules, puis à un moment donné monte le vrai / et passe la main à l'init normal qui s'y trouve.
Ce système m'a toujours semblé tordu, surtout comparé à ce qui se fait avec d'autres noyaux — certains BSD de mémoire, mais je me trompe peut-être — qui consiste à charger le noyau et, à côté, non pas un système de fichiers mais un paquet de modules additionnels. Le noyau ne va alors pas démarrer sur un système temporaire, mais simplement charger ces modules directement depuis la mémoire, et pouvoir monter le vrai / dès le début.
Le système d'initrd est également compliqué à mettre en place, même s'il y a des outils pour cacher cette complexité : il s'agit de rédiger un script d'init temporaire très particulier, d'assembler un système minimaliste suffisant pour ce script, d'ajouter les modules noyau nécessaires, et de mettre tout ça dans une archive. Comparé au seul archivage des modules nécessaires pour un système basé sur des modules additionnels directement chargés par le noyau, c'est clairement compliqué.
Quelqu'un saurait-il d'où vient ce choix pour Linux, qui me semble vraiment étrange ?
[^] # Re: Modules additionnels
Posté par gouttegd . Évalué à  4.
C’est l’un des usages de l’initrd, mais ça ne se limite pas à ça.
L’initrd peut aussi contenir, en plus des modules (et des outils pour les charger), toute sorte d’outils pour réaliser toute sorte de tâches. Par exemple :
Le script d’init qui se trouve dans l’initrd peut être bidouillé à loisir pour y faire plein de choses. J’en connais qui y lancent un démon SSH pour pouvoir déverrouiller un disque chiffré à distance…
Ben oui, mais ça fait plus de choses.
[^] # Re: Modules additionnels
Posté par Renault (site web personnel) . Évalué à  3.
Cela permet aussi d'avoir un shell de secours si jamais le système ne parvient pas à monter la racine pour X ou Y raison.
Ou encore, sur certains systèmes embarqués (dans le passé, aujourd'hui cela est plutôt rare), le système entier tenait dans l'initrd.
[^] # Re: Modules additionnels
Posté par totof2000 . Évalué à  4.
…
Conceptuellement, en quoi est-ce nécessaire d'avoir un initrd pour tout ça ?
Normalement le noyau devrait pouvoir monter au moins un FS / qui sait faire tout ça … c'était d'ailleurs à l'origine la raison de la séparation entre /bin, /sbin et usr/bin + /usr/sbin …
Aujourd'hui on veut virer /bin et /sbin pour tout mettre dans /usr/bin et /usr/sbin, et avoir le nécessaire au démarrage dans initrd … je trouve ça un peu ridicule.
[^] # Re: Modules additionnels
Posté par totof2000 . Évalué à  4.
Il me semble que c'est historique.
Je me trompe peut-être mais ce système (qui s'appelait peut-être autrement autrement à ce moment) date de l'époque ou on démarrait Linux depuis une disquette (voire plusieurs) avec une disquette contenant le noyau, et une autre contenant une image FS compressée.
Mais je peux me tromper, si c'est le cas je suis preneur de toute rectification.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.