Lancer un script avant montage de la partition root

Re-Bonjour tout le monde.

Toujours dans la series des problèmes liés à la création d’image multi-hardware sur linux, il faut que j’initialise un script avant montage de la partition root au boot.

Je m’explique : si on clone un debian ayant comme root hda1 sur une machine sata, on a un joli freeze au demarrage.

Je cherche donc à faire un script qui vérifie si la machine est en sata ou pas (en scannant par exemple /dev si ce repertoire est deja consistué à ce stade du boot), et qui en fonction modifie le parametre root du menu.lst de grub, supprime le script pour qu’il ne s’initialise plus et redemarre la machine.

tout ça c’est bien joli mais je n’arrive pas à initialiser des script à ce stade là, j’ai essayé d’en mettre dans /usr/share/initramfs-tools/scripts/local-top mais ils ne s’executent pas :frowning: , je ne sais pas si c’est vraiment la solution.

Pas trop de doc là dessus sur le net donc je sollicite vos compétences :unamused:

bonjour,
ça me parait tiré par les cheveux, voir impossible dans le cas de figure suivant : # df -h / Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/hda1 250M 189M 48M 80% / debian:/tmp/bzipThis# df -h /boot Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/hda1 250M 189M 48M 80% /

Je ne sais pas, le répertoire /usr/ est aussi monté sur “/” et pourtant le système execute des scripts placés dans /usr/… avant de monter le “/”, donc ce n’est peut-etre pas si impossible… :unamused:

Pour faire cela, il faut se mettre au niveau de l’initrd. J’imagine que tu voudrais un script qui met la racine comme /dev/hda1 ou /dev/sda1 suivant que le disque est SATA ou non. J’ignore si tu peux redéfinir la racine en cours de boot par contre tu peux facilement bouter sur un RAMFS (petit) lequel regarde quel type de disque il a, monte le disque et fait un chroot sur la nouvelle racine (en modifiant le fstab en fonction…) à l’aide de pivot_root en n’oubliant pas de démonter le ramdisk…

Merci, mais ça m’as l’air un peu compliqué tout ça, à chaque boot il faudrais booter sur un ramfs ? ou je pourrais à partir de la changer aussi le menu.lst de grub ? et heuuu comment on crée un RAMFS et comment on boot dessus ? :blush: (toujours vraiment peu de doc sur le net)

Je me demandais si la chose suivante ne fonctionnerait pas:

Tu prends ton initrd

Tu fais

mkdir INITRD ; cd INITRD ; zcat …/initrd | cpio -i

puis dedans tu prévois un script qui fait

mknod root b 8 1

si ta racine est /dev/sda1 et

mknod root b 3 1

si ta racine est /dev/hda1

Tu charges les modules nécessaires pour monter la racine et tu laisses la suite normalement.
Tu refais l’initrd

find . | cpio --quiet -o -H newc | gzip -9 > …/initrd

Tu prends soin de mettre dans grub la racine comme /dev/root et de faire un /dev/root correct dans /dev une fois ta racine monté. Je n’ai pas testé mais ça devrait marcher.

J’ai voulu essayer ta solution mais je n’arrive même pas à decompresser mon initdr :
je l’ai d’abord renommé en .gz, puis decompressé, ça me donne un fichier en " ASCII cpio archive (SVR4 with no CRC) " , je ne peux pas l’ouvrir et si je le monte il me demande le type :s

[quote=“zdude”]J’ai voulu essayer ta solution mais je n’arrive même pas à decompresser mon initdr :
je l’ai d’abord renommé en .gz, puis decompressé, ça me donne un fichier en " ASCII cpio archive (SVR4 with no CRC) " , je ne peux pas l’ouvrir et si je le monte il me demande le type :s[/quote]Je ne vois pas l’interet de le renommer en .gz, mais as tu déployé le contenu de l’initrd avec

zcat <l'initrd que tu veux modifier> | cpio -i comme te l’a dit fran ?

Je l’ai renommé en gz car j’ai vu qu’on pouvais faire cela en cherchant sur le net (sinon on ne peut pas le decompresser avec gzip… oui c’est bizzard).

Mais en effet ça marche avec zcat, j’avais pas compris que c’est cette commande qui decompresais l’initrd :blush: :wink:

J’ai effectué la manip, ça marche nikel, excepté qu’à chaque boot j’ai droit à un “Give root password for maintenance (or type Control-D to continue)” quand je boot sur l’initrd modifié , sans aucune autre indication de defaillance :confused:

Si je fais Ctrl-D le système termine de booter et est opérationnel mais c’est tout de même embêtant :unamused:

[quote=“zdude”]J’ai effectué la manip, ça marche nikel, excepté qu’à chaque boot j’ai droit à un “Give root password for maintenance (or type Control-D to continue)” quand je boot sur l’initrd modifié , sans aucune autre indication de defaillance :confused:

Si je fais Ctrl-D le système termine de booter et est opérationnel mais c’est tout de même embêtant :unamused:[/quote]tu dois avoir un code de retour non nul dans ton script ou un truc comme ça.
Essayes de le terminer par un exit 0, par exemple.

Dis si ça marche car c’est finalement un truc et astuces assez simple…

En fait pour tester j’ai mis le script directement dans le script principal de l’initrd donc je ne pense pas que ce soit ça.

Mais ce qui est bizzard c’est que j’ai deployé l’image système avec l’initrd modifié sur 6 PC et sur aucun n’est apparu ce problème, j’ai donc arrêté de chercher en esperant que ce pb ne refasse plus surface.

Sinon juste comme ça une dernière question, bien que la manip marche parfaitement, ca risque ne pose aucun problèmes d’avoir 2 périphériques “virtuels” (sda1 et root) pour 1 seul périphérique physique ?

Non, ça équivaut à avoir un lien, il n’y a pas de souci. Les noms sont purement conventionnels…

Sinon, il me vient à l’idée qu’un simple étiquetage des partitions avec tune2fs -l aurait peut être pû suffire pour une utilisation de l’identification des partitions indépendante de leur nom symbolique (dans fstab, on designe alors les partitions par leur etiquette LABEL=…, et plus par leur nom de device /dev/…).
Mais malheureusement, contrairement à d’autres grub, celui de debian n’accepte pas un paramètre du genre:
append = “root=LABEL=/ …”, ce qui permettrait d’être generique de bout en bout.
Par contre, j’ai remarqué que le_petit_chat_noir utilisait une désignation basée sur l’UUID du disque (le numero de série) comme dans ce fil ou on voit son fstab:
forum.debian-fr.org/viewtopic.ph … light=uuid
Ca m’interresserait de savoir ou il trouve son UUID (avec les fichiers de udev ?), et si on peut l’utiliser comme paramètre append dans grub.

J’ai moi aussi des disques qui bougent beaucoup, et ça m’enerve que windows soit plus souple que linux sur ce point là.

L’uuid je pense ne résoudra pas mon problème vu que j’aurais des disques différents, par contre cette histoire de label je crois va bien m’aider sous mandriva ou ça fait 3 heures que j’essaye de modifier leur script d’initrd en nash (!!!)

Reste à voir si lors du clonage cet attribut LABEL est conservé, quelqu’un sait ou cette information est mise ?

Apparament sur fedora core et redhat les LABEL sont implémentés par défaut sur le grub donc je n’aurais à priori rien à faire… à voir.

quote="zdude"
Reste à voir si lors du clonage cet attribut LABEL est conservé, quelqu’un sait ou cette information est mise ?[/quote]Ca reste: ça fait partie des infos de superbloc de l’ext, donc c’est copié avec la partoche.[quote=“zdude”]Apparament sur fedora core et redhat les LABEL sont implémentés par défaut sur le grub donc je n’aurais à priori rien à faire… à voir.[/quote]C’est ce qui m’ennuie avec debian, ça marche pas, alors que j’ai fait ça pendant des années avec mes redhat (pas fedora).
Mais je pense que ça vient de l’automatisation avec update-grub qui doit mal récupèrer les options style “append=” dans les “doubles commentaires” de l’automagic.

Je pense plutot que ça vient de l’initrd, sous mandriva, redhat et fedora ils créent un /dev/root automatiquement grace à une directive createRootDev du “shell” nash et font ensuite un pivot_root…j’ai essayé de comprendre comment ça marchait en vain, plus d’info ici -> http://mulix.livejournal.com/84768.html

En effet c’est bien un problème d’initramfs…bizzarement debian utilise une vieille version d’initramfs-tools (ou ne l’utilise peut etre meme pas) pour créer l’initramfs…un petit mkinitramfs -o nomfichier et le tour est joué on peut utiliser les labels :smiley: