initramfs

Posté par ddeted le 17 septembre 2010 à 14:20.

Étiquettes :

sept.

2010

Bonjour,

Voilà, j'ai un problème quelque peu étrange.
J'ai fais des images disques que j'ai préparé pour etre déployé sur des nouvelles machines (a grand coup de tar ;)
L'os utilisé est une UBUNTU 8.4 (c'est pas moi qui choisi...)

Mais souci est le suivant:
Lorsque je boot ma machine apres avoir fais un update-initramfs +update-grub

Le RAID ne se monte pas :(

je me retrouve donc dans le initramfs> la si je vais voir le /etc/mdadm/mdadm.conf je constate que les infos de ma conf ne sont pas la!!! je m'explique:

Dans la ligne ARRAY= j'ai défini l'option devices=/dev/sda1,/dev/sdb1 et bien je me retrouve a la place de ma definition de devices= avec des UUID=xxxxxxxxxxxx:xxxxxxxxxxx:xxxxxxxxx:xxxxxxxxxxxx

Si je remove UUID=blabla et que je le remplace par devices=blabla je peu remonter mon RAID puis mon lvm et de la booter...

Ce que je ne comprend pas c'est que mon mdadm.conf présent dans le initramfs soit réécri (probablement par udev?) avec des infos qui ne lui permette pas de booter...

=> De même si je boot avec un LiveCD et que je fais un
gunzip -c initrdfile | cpio -i (pour consulter l interieur de mon initrd)

Je constate bien qu'il ya le fichier /etc/mdadm.conf avec les bonnes valeurs...

Que puis je faire ?

Merci d'avance pour vos retour!

# Avis de newbee

Posté par ze_lionix (site web personnel) le 17 septembre 2010 à 16:36. Évalué à 2.

Salut,

Je dois avouer que je ne pratique pas l'initramfs ( je sais faut que je m'y mette, c'est comme passer de Lilo à Grub, faut se bouger ! ) et donc c'est un avis de newbee qui n'y connaît rien que je te donne ici... Mais comme personne n'a répondu et que c'est toujours bon d'avoir un avis extérieur, je pense que c'est peut être la commande update-initramfs qui modifie la chose, à vérifier....

Sinon des pistes potentielles :
- En regardant les man j'irai fouiller dans la conf /etc/mkinitramfs/conf.d/ et dans initramfs-tools ( mode debug ? ).
- Faire une tache post-install, qui après ton update-grub fait la manipulation de récupération...
Fuse : j'en Use et Abuse !
# RAID et fichier de configuration

Posté par Kerro le 17 septembre 2010 à 18:20. Évalué à 2.

En principe, le fichier /etc/mdamd/mdadm.conf n'est pas utilisé lors du montage des partitions. Il est sensé être utilisé uniquement par les outils permettant de manipuler les partitions. En s'il ne contient pas les bonnes infos ça fonctionne tout de même ('faut p't'être pas trop exagérer je pense).

Le RAID logiciel est géré par le noyau (module md) et ne se préoccupe jamais du fichier de configuration. Vérifié et revérifié sur Debian Etch et Lenny sur des dizaines de machines.

Je te propose de booter depuis un live-CD et de taper cat /proc/mdstat. En principe tu vois apparaître tes volumes RAID. Si ce n'est pas le cas, c'est qu'ils n'ont pas été créés correctement.
- [^] # Re: RAID et fichier de configuration
  
  Posté par ddeted le 17 septembre 2010 à 18:55. Évalué à 1.
  
  Bonjour,
  
  Tu as raison sur le fait que le fichier se trouve dans le FS et qu'il ne s en preoccupe pas pour booter.
  
  Toutefois je ne parle pas du mdadm.conf qu'il ya sur mon FS mais bien de celui present dans le initrd...
  
  Et c'est ce que je ne comprend pas, il met des UID a linterieur qui semblent provenir de nul part et si dans le shell initramfs je modifie les lignes ARRAY en y ajoutant l output de la commande:
  
  initramfs> mdadm --examine --scan --config=mdadm.conf >> /etc/mdadm/mdadm.conf
  puis
  initramfs> mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1
  
  initramfs> mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2
  Ctrl+C
  
  La ca boot correctement, mon probleme vient donc du fichier mdadm.conf généré lors du boot de linitramfs ;(
  
  Qu en penses tu ?
  - [^] # Re: RAID et fichier de configuration
    
    Posté par Kerro le 17 septembre 2010 à 19:01. Évalué à 2.
    
    Toutefois je ne parle pas du mdadm.conf qu'il ya sur mon FS mais bien de celui present dans le initrd...
    Pareil.
    Sinon comment serait-il possible de monter un RAID alors que tu bootes depuis un liveCD ou depuis un autre disque ?
    
    J'ai une procédure pour passer un système de "normal" à "RAID" à distance (moyennant le fait qu'il faut au moins 2 disques). Cette procédure ne touche pas à l'initrd. Ni à /etc/mdadm/mdadm.conf, ni même à /boot/grub/grub.conf (par contre pour Grub 2 c'est mieux de modifier, mais ça marche sans).
    Et dans ce cas précis, le contenu de l'initrd n'a jamais pu être au courant à l'avance de la manière dont je configurerai mon RAID.
    - [^] # Re: RAID et fichier de configuration
      
      Posté par ddeted le 17 septembre 2010 à 20:19. Évalué à 1.
      
      Merci pour ce retour,
      Je suis completement d'accord avec toi, toutefois il me semble tout de meme que lors du demarrage l'initrd doit avoir pris les confs en questions pour booter du RAID...
      
      Quoiqu'il en soit j'ai fai tellement de bidouilles en tout genre que je me suis dis que j'allais ecraser mon RAID et tout reconstruir...
      
      Malgres tout cela n explique pas pourquoi je suis obligé de modifier le mdadm.conf dans mon initramfs pour pouvoir booter.
      
      Qu en penses tu alors ?
      - [^] # Re: RAID et fichier de configuration
        
        Posté par Kerro le 17 septembre 2010 à 22:27. Évalué à 2.
        
        J'ai une hypothèse. Mais ça reste incertain.
        
        Le noyau démarre. Il lance les RAID comme un grand. Il numérote les RAID selon le contenu du superblock du RAID. Ensuite il se base sur mdadm.conf pour renuméroter (hypothèse, hein, pas sûr).
        
        Donc si tu supprimes les informations contenues dans ton mdadm.conf tu peux éventuellement démarrer convenablement.
        
        Vérifier les infos:
        mdadm --detail /dev/mdx # Preferred Minor : x (si x=2 alors /dev/md2) mdadm --examine /dev/sdax # même chose mais à partir du périphérique sous-jacent, et non pas /dev/mdx
        
        Modifier la numérotation d'une partition RAID (une solution parmis d'autres):
        mdadm --stop /dev/mdx mdadm --assemble --verbose --update=super-minor /dev/mdx /dev/sday /dev/sdby
        
        Note: c'est lourd les espaces multiples qui ne sont pas pris en compte
        
        Ou alors simplement tu t'es emmêlè les pinceaux dans tes partitions à force de buter sur le problème.
# Mmmhh …

Posté par benoar le 17 septembre 2010 à 22:05. Évalué à 2.

Tiens c'est marrant je suis en train de me battre pour le même genre de problème mais dans un contexte complètement différent. Mais je ne pense pas que ça ait beaucoup de rapport (le code qui me foutais des UUID dans le fichier de conf de mon bootloader est le script post-installation du paque linux-base ; d'une, ça doit dater d'après ta Ubuntu, et de deux dans ton cas je vois pas pourquoi le postinst d'un paquet serait appelé…)

Mais je te conseillerais de bien vérifier le contenu de ton initramfs après ton update-initramfs, avant de rebooter, afin d'être sûr que ce n'est pas ça le problème, parce que c'est vrai que là, tel-quel, c'est louche.
# une piste pour te dépanner

Posté par snurpsss le 23 septembre 2010 à 17:34. Évalué à 1.

Je suis sous debian squeeze, et y a 2 jours j ai une un apt-get upgrade qui m'a forcé a me replongé la dedans.

Avant cela, comme toi, je me suis retrouvé sans partition root après un apt-get (pendant lequel je n'ai pas pris le temps de lire les messages m'avertissant de vérifier ma configuration mdadm avant le prochain reboot.)

L'idée: boot sur un live cd. là normalement ton raid sera toujours pas présent.

Remonte ton raid a la main. (mdadm --assemble, mdadm --help et le man pour les détails)

Chroot ça bien

et aprés il faudra:
Checker tes UUID réels et ceux dans ton fichier de config
mdadm -D /dev/md0
mdadm -E /dev/md0

regénérer un fichier initram fs.
(de mémoire update-initramfs -u -k all ; a vérifier sous ubuntu)

Sous debian, il y a de la doc dans /usr/share/doc/mdad
désungzipper le fichier README.upgrading-2.5.3.gz, tout est dedans...

Courage, c est en forgeant....

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.