# [RÉSOLU]Le topic du n00b qui veut faire un initramfs

## StinGer_Uesugi

Je suis en train de m'installer un HTPC qui me servira aussi de serveur de stockage. Je passe sur le matos (à moins que ça intéresse quelqu'un), je n'ai aucun problème de pilote.

En revanche, je cherche à faire un système avec / en LVM sur RAID 5. Pas taper !   :Embarassed: 

Oui je sais, j'en entends déjà me dire que ça sert à rien de mettre / comme ça etc... Oué OK mais j'ai envie, voilà. Et de toutes façons, si j'avais / monté sur une partition normale, j'aurais /usr sur LVM sur RAID 5 et mon problème serait le même.

Bon donc, du coup, si j'ai bien suivi, il me faut un initramfs qui s'assure que les arrays RAID sont bien assemblées, recherche les volumes LVM et montent tout ça pour passer ensuite au switch_root. J'ai bon ?   :Question: 

J'ai donc cherché les infos sur comment faire un initramfs et comme ce que je veux est vraiment tout petit, je suis parti sur la méthode plus ou moins manuelle en m'inspirant de cette page, c'est-à-dire en utilisant gen_initramfs_list.sh. Évidemment, le kernel est configuré avec le RAID et LVM intégrés dedans...   :Wink: 

De base dans ma liste de fichiers, j'ai busybox et lvm en static et mdadm avec ses p'tites librairies qui lui vont bien. Et mon script init (désolé, j'ai pas le PC devant moi donc je peux pas vous donner la liste exacte, je le ferai dès que je pourrai).

Je fais mon (oui, j'utilise bz2 en compression par défaut dans le kernel) :

```
scripts/gen_initramfs_list.sh -o /boot/initrd.cpio.bz2 /usr/src/initramfs/initramfs_list
```

Allons-y donc pour le boot. Et bah là, tout se passe comme si il se passait rien ! Donc forcément, ça ne boot pas. Mon kernel se plaint de ne pas pouvoir "sync VFS", blablabla... Bref, il a pas de root. J'ai déraciné mon kernel, le pauvre !

Après un petit check, il s'avère que mon script commençait par :

```
#!/bin/sh
```

Et non par :

```
#!/bin/busybox sh
```

J'ai corrigé ça et là, ça va mieux. Mais pas vraiment en fait. Je fais des echo pendant mon script, pour voir ce qu'il se passe, donc je sais que l'initramfs s'exécute bien. Cependant, echo fonctionne bien, mais pas lvm (vgscan/vgchange). En fait, j'ai une erreur "Path not found" avec lvm. J'ai essayé avec lvm tout court, en faisant un export ou non de PATH, voire directement /sbin/lvm. Mais j'ai toujours le même problème. Et là où ça me dérange encore plus, c'est que normalement, je devrais avoir un shell busybox puisque je finis mes commandes par :

```
commande || rescue_shell "Une erreur est survenue."
```

Mais ce n'est pas le cas. Alors j'ai essayé de lancer directement le shell busybox sans rien faire d'autre, par :

```
#!/bin/busybox sh

busybox --install -s

exec /bin/sh

```

Mais là, idem, j'ai une erreur "busybox is not an absolute path". Donc encore un problème de chemin. En fait, j'ai l'impression qu'il n'y a pas de / ni même aucune arborescence. Pourtant, j'ai extrait l'initram pour vérifier, et tout y est bien présent. Je ne comprends pas quel est le problème. Qu'est-ce que je fais pas bien ? Où j'ai glissé chef ?

Merci pour votre aide.   :Smile: 

----------

## GentooUser@Clubic

Je n'utilise pas scripts/gen_initramfs_list.sh mais je vais essayer de voir ce qu'il donne, c'est quoi le contenu de ton  "/usr/src/initramfs/initramfs_list" ?

Juste au passage busybox est bien compilé avec l'useflag static ?

Perso j'utilise un script maison pour générer mon initrd (qui ne se charge cependant que d'afficher le bootsplash et monter /), mais tu peux toujours t'en inspirer.

```

#!/bin/sh

# variables

initrd="/boot/initramfs-generic.img"

# helper functions

pinfo() {

   echo "$@"

}

perror() {

   echo "ERROR: $@" >&2

   exit

}

# user check

if [ $UID -ne 0 ] ; then

   perror "you must be root"

fi

# start script

pinfo "generating initrd..."

# create working directory

root=`mktemp -d`

# populate whith standard directory tree

install -d -o 0 -g 0 -m 755 $root/{newroot,bin,sbin,lib64,var,run,run/lock,run/initramfs,run/plymouth,proc,dev,sys}

# make useful symlinks

ln -s lib64 $root/lib

ln -s ../run $root/var/run

ln -s ../run/lock $root/var/lock

# install busybox

if [ ! -x /bin/busybox ] ; then

   perror "/bin/busybox is missing"

fi

nm -D /bin/busybox &>/dev/null

if [ "$?" -ne 1 ] ; then

   perror "/bin/busybox is dynamically linked"

fi

install -o 0 -g 0 -m 755  /bin/busybox $root/bin

busybox --install -s $root/bin

# dump current keymap

busybox dumpkmap > $root/run/initramfs/kmap

# merge plymouth overlay

if [ ! -x /usr/libexec/plymouth/plymouth-populate-initrd ] ; then

   perror "/usr/libexec/plymouth/plymouth-populate-initrd is missing"

fi

/usr/libexec/plymouth/plymouth-populate-initrd -t $root

# create init script

cat >$root/init <<'ENDSCRIPT'

#!/bin/sh

# set variables default values (overwritables by the kernel command line)

splash=0

shell=0

root=""

rootfstype=""

init="/sbin/init"

parse_cmdline() {

   local _cmdline=`cat /proc/cmdline`

   for i in $_cmdline ; do

      case $i in

      rd.shell)

         shell=1

         ;;

      splash)

         splash=1

         ;;

      root=*)

         local _val=`echo $i | cut -d'=' -f2-`

         [ ! -z $_val ] && root=$_val

         ;;

      rootfstype=*)

         local _val=`echo $i | cut -d'=' -f2-`

         [ ! -z $_val ] && rootfstype=$_val

         ;;

      init=*)

         local _val=`echo $i | cut -d'=' -f2-`

         [ ! -z $_val ] && init=$_val

         ;;

      esac

   done

}

get_root() {

   local _type=`echo $1 | cut -d= -f1`

   if [ $_type == "LABEL" ] || [ $_type == "UUID" ] ; then

      local _id=`echo $1 | cut -d= -f2`

      local _rval=`findfs "$_type"="$_id"`

   else

      local _rval=$1

   fi

   echo $_rval

}

rescue_shell() {

   echo "$@"

   loadkmap < /run/initramfs/kmap

   exec /bin/sh

}

# clean grub gibberish

clear

# setup initramfs

mount -t proc none /proc

mount -t sysfs none /sys

mdev -s

# parse kernel cmdline to fill variables

parse_cmdline

# drop user to the initramfs rescue shell if requested

[ $shell -eq 1 ] && rescue_shell "dropping to initramfs shell (reason: requested by kernel cmdline:rd.shell)"

# show splash (as soon as possible)

if [ $splash -eq 1 ] ; then

   plymouthd --pid-file /run/plymouth/pid

   plymouth --show-splash

fi

# mount rootfs

if [ ! -z $rootfstype ] ; then

   local _mount_opts="-t $rootfstype -o ro"

else

   local _mount_opts="-o ro"

fi

mount $_mount_opts `get_root $root` /newroot

# if something wrong, drop user to the initramfs rescue shell

if [ $? -ne 0 ] ; then

   [ $splash -eq 1 ] && /bin/plymouth --hide-splash

   rescue_shell "dropping to initramfs shell (reason: unable to mount rootfs:$root)"

fi

# update plymouth root

[ $splash -eq 1 ] && plymouth --newroot=/newroot

# cleaning up

umount /proc

umount /sys

# switching to new root

exec switch_root /newroot $init

ENDSCRIPT

chown 0:0 $root/init

chmod 755 $root/init

# package initrd

if [ -e $initrd ] ; then

   cp $initrd ${initrd}.old

fi

cd $root

find . | cpio -o --format="newc" 2>/dev/null | gzip > $initrd

pinfo "initrd saved to $initrd"

# cleaning

pinfo "cleaning..."

rm -r $root

pinfo "done."

```

----------

## kwenspc

ou alors vous utilisez genkernel...

----------

## StinGer_Uesugi

Résolu !

Non je ne dirai pas comment. Si, je dois vraiment le dire ?   :Embarassed:   :Embarassed:   C'est sûr ?

J'ai inclu sh dans mon initramfs (parce qu'à terme, je voudrais même dégager busybox, peut-être...). Mais pourquoi sh ne fonctionnait pas me demanderez-vous ? Et bah tout simplement parce que c'est bien beau de mettre ses librairies, mais encore faut-il les mettre au bon endroit !

Dans mon initramfs_list, j'avais fait un répertoir /lib et mis mes librairies dedans. C'est en voyant ton script GentooUser@Clubic que j'ai vu mon erreur.

Du coup, j'ai bien changé en /lib64 et tout fonctionne ! Enfin nan en fait. Quand je scan mes volumes LVM, il me crée pas ma jolie arborescence /dev/VGNAME/LVNAME. Mais bon ça, c'est anodin. Y a tout ce qu'il faut dans /dev/mapper. Du coup, j'ai pu booter mon PC en LVM sur RAID 5 ! \o/

----------

## truc

j'préviens, c'est un peu off tout ça...

 *kwenspc wrote:*   

> ou alors vous utilisez genkernel...

 

Bah, avant j'aurais dit, meuh, non, autant le faire vite fait bien fait à la mano. Je n'ai jamais vraiment regardé comment fonctionnait genkernel, par contre, je m'intéresse à dracut ces derniers temps et je trouve que c'est vraiment pas mal foutu. À éviter pour ceux qui ne veulent pas entendre parler de udev cela dit!

Pour les autres, le fonctionnement est vraiment décrit par ce qui est dit sur la description officielle du projet: *Quote:*   

> "The initramfs has (basically) one purpose in life -- getting the rootfs mounted so that we can transition to the real rootfs. This is all driven off of device availability"

 

En gros, dracut vous génère un initramfs avec des règles udev qui vont lancer certaines actions lors de la détection des périphériques. Cette une démarche très souple, car ainsi, pas besoin d'avoir un initramfs différent et si tu fais du luks/lvm ou du lvm/luks (l'un au dessus de l'autre ou vice versa) lorsque les périphes apparaissent les helpers sont executés il n'y a pas d'ordre prédéfinis et dans l'absolu, l'initramfs généré par dracut n'en a aucune idée, "lui", il attend juste que le bon périphérique fasse surface!

Bref, c'est pas mal et pour couronner le tout, (ceux qui crachent sur udev ont, j'éspère, arrêter de lire depuis!), les dernières versions s'intègrent très bien avec systemd(bon, je n'ai pas vraiment connnu le temps avant systemd pour dracut, donc, j'peux pas vraiment témoigner sur cet aspect) et notamment sur la possibilité de redonner la main à l'initramfs lors de l'extinction pour pouvoir démonter proprement votre partition racine(défaire le raid, fermer le périphérique chiffré, désactiver le lvm etc) (avouez que vous avez penser à quelque chose comme ça au moins une fois dans votre geekette de life!)

----------

## boozo

/off too : Je ne saurai vraiment dire pourquoi mais... je me sens concerné par certaines remarques  :Laughing: 

@truc:> En fait, je n'ai pas d'aversion profonde pour dracut c'était juste que genkernel faisait tout autant l'affaire pour un initramfs et en faire un à la main aussi du reste. Après la question d'avoir un un temps de compilation "ultra-optimisé" ou une séquence de boot 2,3ms plus rapide voire un super fb blinkeyes... bon soit ce sont des arguments certes mais pas une débauche de fonctionnalités supplémentaires à mon sens.

Je ne suis pas un exemple très loin de là p.e. juste un enduser comme un autre et personnellement, mon laptop boote 1,2 fois par jours (le serveur 1/mois au pire)... je peux bien prendre 20min pour tweaker mon kernel 1x/mois et attendre 2 secondes de plus que la machine soit up le temps de souffler sur mon café   :Wink: 

Mais c'est une question de goûts ou de couleurs et que chacun reste libre de faire ce que bon lui chante me semble important.  

Concernant le gain pour lvm+luks là encore j'ai juste une remarque : avant ces outils d'assistance on s'en sortait tout aussi bien pour le chiffrage non ?

(Aïe! flutte je me nombrilise encore mais c'est pas fait exprès) j'ai bien mon netbook qui avait déjà lvm+luks actif avant dracut sans pb outres mesures aux séquences de boot ou à l'arrêt ?!   :Shocked: 

C'est vraiment pas pour jouer les vieux c*** c'est juste pour en relativiser l'importance. D'autant plus quand on voit la sensibilité "particulière" de certains des acteurs du chapeau cramoisi sans parler de leurs méthodes  :Wink:  (oui, oui, j'en ai autant pour udev et quelque part ces sujets sont un brin liés quand même mais je digresse et c'est un autre débat).

Après si les outils en question rendent effectivement cette gestion/administration quotidienne plus aisée soit j'adopte mais a contrario p.e. pour compiler la quenelle - vu la fréquence d'utilisation et le gain engendré - combien s'en servent ici vs ceux qui s'y colle à l'ancienne mode ?

Si on frappe au grand max du fifty-fifty ce qui ne m'étonnerait guère, c'est que l'avancée n'est pas aussi évidente et il me semble légitime d'au moins se poser la question non ?

Je suis vraiment devenu si "aigri" en ce moment que je ne vois plus l'avancée du Monde ?   :Crying or Very sad:  Eclairez-moi siouplait !

----------

## truc

Dégoutté, j'ai pris mon temps pour faire une réponse bien complète et là c'est le drame, j'ai merdé en la postant, j'l'ai perdue:(

J'en refais une version courte, n'hésite pas à me dire si je ne suis pas clair.

 *boozo wrote:*   

> /off too : Je ne saurai vraiment dire pourquoi mais... je me sens concerné par certaines remarques 

 Peut-être, mais rien d'aggressif en tout cas, puisque je partage en grande partie les craintes

 *Quote:*   

> @truc:> En fait, je n'ai pas d'aversion profonde pour dracut c'était juste que genkernel faisait tout autant l'affaire pour un initramfs et en faire un à la main aussi du reste. Après la question d'avoir un un temps de compilation "ultra-optimisé" ou une séquence de boot 2,3ms plus rapide voire un super fb blinkeyes... bon soit ce sont des arguments certes mais pas une débauche de fonctionnalités supplémentaires à mon sens.
> 
> Je ne suis pas un exemple très loin de là p.e. juste un enduser comme un autre et personnellement, mon laptop boote 1,2 fois par jours (le serveur 1/mois au pire)... je peux bien prendre 20min pour tweaker mon kernel 1x/mois et attendre 2 secondes de plus que la machine soit up le temps de souffler sur mon café  
> 
> Mais c'est une question de goûts ou de couleurs et que chacun reste libre de faire ce que bon lui chante me semble important.  
> ...

 

Non, mais je n'ai pas du tout parlé de gain en vitesse et d'ailleurs, pas non plus de gain en fonctionnalité(EDIT: ah si j'ai parlé de la possibilité de rebasculer sur l'initramfs lors de l'extinction  :Embarassed: , mais c'est tout je crois! ).

J'ai juste dit que dracut avait une manière astucieuse de fonctionner, ou plutôt, l'initramfs généré par dracut fonctionne d'une manière astucieuse et originale par rapport aux initramfs que je connaissais jusqu'alors. Que l'on aime ou pas udev n'entre pas en compte, dracut s'appuie sur les hooks rendus disponibles par le gestionnaire de périphérique(ici udev, mais ce n'est pas la question, ça aurait pu être un autre!)

 *Quote:*   

> Concernant le gain pour lvm+luks là encore j'ai juste une remarque : avant ces outils d'assistance on s'en sortait tout aussi bien pour le chiffrage non ?
> 
> (Aïe! flutte je me nombrilise encore mais c'est pas fait exprès) j'ai bien mon netbook qui avait déjà lvm+luks actif avant dracut sans pb outres mesures aux séquences de boot ou à l'arrêt ?!   

 

alors, c'est faisable à la main, il n'y a pas de problème là dessus, c'est ce que je faisais encore très récemment. On s'est peut-être mal compris, mais dracut est facultatif, c'est un outil mis à ta disposition pour générer un initramfs. il n'est pas du tout imposé comme peut l'être systemd

Au delà de son fonctionnement astucieux et original, l'avantage de cet outil, et plus généralement de ce genre d'outils (genkernel/dracut) est d'uniformiser la création de l'initramfs et ainsi d'éviter à chacun de devoir refaire manuellement un script /init qui a déjà été fait 394000 fois auparavant.

Dans le cas des combinaisons luks/lvm/mdadm/etc... Je trouve que dracut a aussi un avantage par rapport à un script /init standard: il ne nécessite pas de se poser les questions existentielles qu'on serait amené à se poser si on essayait de faire un initramfs (et donc très probablement un script /init) un minimum générique:

par exemple, je fais un lvchange -ay avant luks? après? les deux? avant mdadm? après? les deux? (ou cas où pour couvrir tous les cas possibles)

Ici, par exemple, si un périphérique du type crypto_LUKS apparait, c'est le hook de cryptsetup qui se lance, ce hook est paramétrable etc...

 *Quote:*   

> C'est vraiment pas pour jouer les vieux c*** c'est juste pour en relativiser l'importance. D'autant plus quand on voit la sensibilité "particulière" de certains des acteurs du chapeau cramoisi sans parler de leurs méthodes  (oui, oui, j'en ai autant pour udev et quelque part ces sujets sont un brin liés quand même mais je digresse et c'est un autre débat).
> 
> Après si les outils en question rendent effectivement cette gestion/administration quotidienne plus aisée soit j'adopte mais a contrario p.e. pour compiler la quenelle - vu la fréquence d'utilisation et le gain engendré - combien s'en servent ici vs ceux qui s'y colle à l'ancienne mode ?
> 
> Si on frappe au grand max du fifty-fifty ce qui ne m'étonnerait guère, c'est que l'avancée n'est pas aussi évidente et il me semble légitime d'au moins se poser la question non ?
> ...

 

Je ne suis pas du tout fan de la méthode utilisée pour faire ce que l'on perçoit comme un gros forcing pour systemd. Par contre, mon impression sur le produit évolue.

Je pense maintenant qu'il y a eu un gros pushing de barbar d'un POC (Proof Of Concept pour ceux qui ne suivent pas!) systemd, et c'est ça et les défauts de ce POC qui ont, semble t'il, déchainer le plus les foules.

Maintenant, et c'est encore un avis très personnel, en suivant un peu l'actualité des développements autour de systemd, j'aurais envie de dire que les choses évoluent et que ça semble prendre la bonne direction et que les manquements sont progressivement comblés/corrigés.

Maintenant pour en revenir à dracut, j'dirai juste que c'est un outil disponible(pas imposé) permettant d'uniformiser la création des initramfs

----------

## boozo

@truc:> T'inquiète je n'ai pas du tout mal pris tes remarques au contraire c'était intéressant et amusant   :Wink: 

Pour le gain de performances notamment c'est un point qu'a fait remonter Gentoo_User@Clubic et vu qu'il vient aussi des méthodes de "l'âge de pierre" pour s'aventurer du côté obscur, je ne vois pas pourquoi il donnerait des indices erronnés là-dessus. Le gain doit y être je n'en discute pas la véracité ; j'ai juste souligné qu'à mon sens cela n'était pas un critère de choix  me laisser pour ce type d'outils.

Au-delà de çà, je partage également ton avis sur la standardisation et la non adhérence à une distro lui confère également un avantage indéniable par rapport genkernel. D'ailleurs, c'est même un brin étonnant du fait de la logique d'intégration verticale qu'ils ont et même si rien n'est (plus/encore?) obligatoire, je crains que ce ne soit qu'une question de temps... Timeo danaos et dona ferentes  :Twisted Evil: 

Je pense ne pas être différents des autres et je préfère également un script éprouvé à toutes solutions à roulettes réalisées chacun dans son coin à chaque génération - sauf si c'est une valeur pédagogique/didactique (et les arguments "parceque c'est bien bien mieux scripté" ou "c'est plus posix si c'est moiquilaifaittoutseulparcequejesuisunebete" ne me touchent pas). Cependant je peux aussi comprendre le besoin d'avoir quelque chose de "simple", qui ne fait qu'1,2 étapes parce qu'on n'utilise que cela mais qui le fait _bien_. Et c'est là un achoppement qui est souvent mal géré i.e. si je m'autorise à faire un parallèle avec les solutions de backup.

Et les choix de méthodes de chiffrage des volumes est aussi un bon exemple en effet. J'ai ch** des bulles de ph2 lorsque je me suis penché sur la question et épluché ce qu'on trouvait sur le web   :Mad:   et les remarques de cachorro à ce sujet (un mods gentoo pour ceux qui connaissent) que je ne suis laisser aller à relire récemment pour les besoins d'un fil similaire, m'ont semblé une fois encore plus vraies que jamais. Donc une solution "simple", et "claire" pour gérer ces besoins une bonne fois pour toute n'en sera que plus profitable pour tous les utilisateurs ne serait-ce que pour en démocratiser l'usage   :Smile: 

Bon... maintenant que j'ai tourné et viré pour pas avoir l'air... je vais voir... je vais peut-être me laisser convaincre d'y goûter un de ces quatre qui sait   :Wink: 

----------

## El_Goretto

Ben tu vois, c'est intéressant, je ne pensais pas que dracut avec une si forte adhérence avec udev.

Merci pour toutes ces infos aux divers tritouilleurs de neurones  :Wink: 

Bon, ben je regarderai genkernel, tant pis pour plymouth  :Very Happy: 

----------

## xaviermiller

dracut c'est pas redhat ?

----------

## El_Goretto

 *XavierMiller wrote:*   

> dracut c'est pas redhat ?

 

Si si, dracut/udev/systemd/redhat, juste que du bon.

----------

## xaviermiller

C'est moins pire que l'OS propriétaire qui s'envoie dans l'espace   :Laughing: 

----------

## boozo

Ouaip faut pas diaboliser non plus ; ils sont des contributeurs de qualité malgré tout et c'est pas parce qu'un de leur gonz à l'ego surdimentionné met en boule tout le monde qu'ils sont tous bon à mettre au panier... en revanche "Ils" ont une franche responsabilité de le laisser faire sans intervenir (quoique d'après ce que dis truc : des choses changent parait-il... après, c'est peut-être l'arbre qui cache la forêt   :Rolling Eyes:  )

La logique d'intégration verticale est plus à craindre que l'outil lui-même à mon sens et dans leur optique, entre ces 3 outils, il y a une certaine "cohérence globale" ou inversement. Après, si les adhérences de ces différents services n'est pas aussi forte que çà y'a quand même des choses à conserver/transposer chez nous peut-être ->

 *truc wrote:*   

> (...) J'ai juste dit que dracut avait une manière astucieuse de fonctionner, ou plutôt, l'initramfs généré par dracut fonctionne d'une manière astucieuse et originale par rapport aux initramfs que je connaissais jusqu'alors. Que l'on aime ou pas udev n'entre pas en compte, dracut s'appuie sur les hooks rendus disponibles par le gestionnaire de périphérique (ici udev, mais ce n'est pas la question, ça aurait pu être un autre!)

 

----------

