Journal initrd est mort, bon débarras

Posté par bubar🦥 le 02 mai 2017 à 17:59. Licence CC By‐SA.

Étiquettes :

-2

mai

2017

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) le 02 mai 2017 à 18:18. Évalué à 8.

ne pas utiliser [de] chiffrement

Beurk.
- [^] # Re: .
  
  Posté par Octabrain le 03 mai 2017 à 09:40. Évalué à 10.
  
  Ouais, du coup initrd n'est pas dying du tout, merci pour le titre putaclick...
- [^] # Re: .
  
  Posté par Sébastien Koechlin le 03 mai 2017 à 10:27. É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 ⛧ le 03 mai 2017 à 17:47. É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 le 04 mai 2017 à 12:57. É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) le 04 mai 2017 à 13:16. É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 le 04 mai 2017 à 18:16. Évalué à 2.
        
        c'est pas mal comme fonctionnalité par exemple
        
        Pour changer de disque, sur machine personnelle alors... :
        
        sur mon portable ou sur mon netbook, il va falloir brancher un autre disque comme buffer, l'ajouter à LVM, demander à LVM de retirer l'ancien disque, de le retirer physiquement de la machine pour le remplacer par le nouveau, Ensuite il faudra l'ajouter à LVM et enfin demander à LVM de retirer le disque dur buffer du LVM...
        
        sur mon fixe, autant SATA est hotplug autant ouvrir la bécane à chaud et risquer de toucher d'autres câbles ça me tente moyen
        
        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) le 11 mai 2017 à 17:34. Évalué à 4.
        
        Donc oui c'est joli comme fonctionnalité, mais l'utilité est plus faible que ce que l'esthétisme technique ne le fait croire.
        
        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 le 11 mai 2017 à 18:51. É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 le 04 mai 2017 à 19:29. Évalué à 3.
        
        Ç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.
        
        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 le 04 mai 2017 à 19:33. É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 le 05 mai 2017 à 08:48. É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.
      
      Tu peux aussi faire une seule partition, c’est encore plus simple.
      - [^] # Re: .
        
        Posté par totof2000 le 05 mai 2017 à 10:57. Évalué à -3.
        
        Tu peux aussi faire une seule partition, c’est encore plus simple.
        
        Non.
# Mouais

Posté par Christophe le 02 mai 2017 à 19:47. É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 le 02 mai 2017 à 21:50. Évalué à 1.

Ces amusements ont leurs jours compté aujourd'hui, car « initrd is dying »
.Sur Fedora (arch aussi ??) il n'est plus nécessaire.

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) le 02 mai 2017 à 23:57. É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 le 03 mai 2017 à 10:10. É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 le 03 mai 2017 à 16:17. É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.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 03 mai 2017 à 08:00. Évalué à 7.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# Récent '

Posté par claudex le 03 mai 2017 à 08:15. É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 le 03 mai 2017 à 09:50. É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, Mastodon) le 03 mai 2017 à 16:58. É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 le 03 mai 2017 à 17:36. Évalué à 4.
    
    J’ai déjà utilisé l’initrd pour pouvoir démarrer une carte sur le « disque » racine dont le driver était un ~~(削除) blob (削除ここまで)~~ module 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 le 03 mai 2017 à 11:14. É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 le 03 mai 2017 à 13:29. É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 le 03 mai 2017 à 16:20. Évalué à 2.
  
  Euh ... Pourquoi ne pas utiliser une IP plutôt qu'un DNS ?
  - [^] # Re: PARTUUID
    
    Posté par kna le 03 mai 2017 à 18:51. É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 le 04 mai 2017 à 08:49. É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 le 03 mai 2017 à 23:45. Évalué à 4.
    
    Euh ... Pourquoi ne pas utiliser une IP plutôt qu'un DNS ?
    
    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) le 03 mai 2017 à 23:50. É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 le 04 mai 2017 à 10:26. Évalué à 3.
      
      Il faudrait trouver une solution pour cela, et ce serait le système parfait.
      
      Ç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 le 04 mai 2017 à 21:10. É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 le 05 mai 2017 à 10:54. É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) le 04 mai 2017 à 09:17. É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) le 04 mai 2017 à 10:22. É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 le 04 mai 2017 à 14:10. Évalué à 4.
  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
  
  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 :
  - cryptsetup (pour ouvrir une partition chiffrée) ;
  - lvm (pour ouvrir un volume logique) ;
  - mdadm (pour ouvrir un volume RAID) ;
  - et des choses plus exotiques encore, genre un driver de lecteur de cartes à puce pour déverrouiller un disque chiffrée en utilisant une clef stockée sur une smartcard...
  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...
  
  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é.
  
  Ben oui, mais ça fait plus de choses.
  - [^] # Re: Modules additionnels
    
    Posté par Renault (site web personnel) le 05 mai 2017 à 10:02. É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 le 05 mai 2017 à 16:50. Évalué à 4.
    
    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 :
    
    ...
    
    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 le 05 mai 2017 à 11:03. Évalué à 4.
  
  Quelqu'un saurait-il d'où vient ce choix pour Linux, qui me semble vraiment étrange ?
  
  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.