Redimensionner (reduire) un RAID et rebooter

[16ar]

Bonjour,

J'ai une dédibox et je souhaite faire une configuration un peu hors des clous : en dehors du /boot, je veux que tout soit chiffré.

Seulement, l'installation de la dedibox se fait quasi automatiquement et ca donne une machine avec

/boot 200M = RAID 1 /dev/md0 entre /dev/sda1 et /dev/sdb1 (200 Mo chacun)

/ 480G = RAID 1 /dev/md1 entre /dev/sda2 et /dev/sdb2 (480Go chacun)

swap = /dev/sda3 et /dev/sdb3

Toutes les partitions sont primaires.

En fait, en premier, je souhaite redimensionner la partition / a 30Go et créer une partition /home de 450 Go.

Ce que j'ai donc fait :

* redimension du FS / à 25 Go (resize2fs /dev/md1 25G)

* redimension de la partition md1 a 30Go (mdadm --grow /dev/md1 --size=31457280 ) (31457280 = 30x1024x1024)

* suppression d'un disque du RAID / (mdadm --manage /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2)

* suppression du superbloc sur ce device (mdadm --zero-superbloc /dev/sdb2)

* suppression de la partition /dev/sdb2 avec cfdisk

* création d'une partition primaire /dev/sdb2 de type FD (linux raid autodetect) de 32000Mo avec cfdisk

* création d'une partition primaire /dev/sdb4 de type 83 (linux) de 450Go avec cfdisk

* rajout du device /dev/sdb2 dans l'array : (mdadm --manage /dev/md1 --add /dev/sdb2)

* vérification de la synchronisation/reconstruction du RAID (watch cat /proc/mdstat)

Une fois cela fait, je re-vais a l'étape 3 en supprimant /dev/sda2 du RAID et je continue jusqu'a l'étape 9.

Formidable, mon RAID 1 / est reconstruit, je peux le monter sans soucis et vérifier/modifier son contenu. Mais je veux redémarrer sur mon RAID 1 / et la, ca ne démarre pas.

L'UUID de la partition ext4 de /dev/md1 n'a pas changé, c'est bien celle qui est dans le /etc/fstab et dans le /boot/grub/grub.cfg du systeme. Comme c'est une dedibox, je ne peux pas savoir ce qui a planté au démarrage. Pour moi, ca devrait bien fonctionner.

Une idée ?

[fabien29200]

Salut !

Comment détermines-tu l'UUID ?

mdadm a son propre UUID indépendant de celui que tu as par blkid.

[16ar]

j'utilise la commande blkid toute seule. Elle me donne le meme resultat en UUID que ce que je peux voir avec ls /dev/disk/by-uuid/ (sauf que y'en a moins affiché dans ce repertoire : typiquement les volumes "physique" RAID /dev/sda1, /dev/sdb1, /dev/sda2, /dev/sdb2)

Mais en effet, dans /etc/mdadm/mdadm.conf, il y'a des UUID defini pour un RAID, mais je ne le vois nulle part d'autre que dans ce fichier de configuration

[fabien29200]

Exact. Mais ce fichier mdadm.conf est aussi dans l'initrd.

Du coup, si ton UUID mdadm a changé et que tu n'as pas mis à jour l'initrd, mdadm ne retrouve plus ton raid associé à ton /dev/md0.

Essaie un coup de : update-grub pour mettre à jour ton initrd.

[16ar]

En effet, l'UUID des ARRAY md0 et md1 ont changé, mais je n'avais pas fait gaffe. Et j'avais rajouté des options devices=/dev/sda1,/dev/sdb1 apres l'UUID, or ils sont ignorés, c'est soit on identifie par UUID, soit par devices.

(explications pour ceux qui n'avait pas compris comme moi : (

l'UUID indiqué dans le mdadm.conf est l'identifiant de l'ARRAY, pas l'identifiant d'une partition ou autre. Quand on créé un array (mdadm --create $peripheriqueArray $peripheriqueBloc1 $peripheriqueBloc2 ) ou quand on reassemble un array (mdadm --assemble $peripheriqueArray $peripheriqueBloc1 $peripheriqueBloc2 ), mdadm créer le superbloc dans $peripheriqueBloc1 et $peripheriqueBloc2 et renseigner l'UUID de l'array dont font partie ces périphérique de bloc)

Ensuite, quand on créé un filesystem sur ce nouveau péripherique de bloc qu'on a créé (qui n'est d'autre que notre array RAID, /dev/mdX), linux va lui assigner un UUID de partition/FS qui sera listé dans /dev/disk/by-uuid qui n'aura rien a voir avec l'UUID de mdadm.conf

Bon, en attendant, ca ne marche toujours pas.

J'ai fait a peu pres la meme configuration que ma dedibox sur une virtualbox, avec 2 disques en RAID 1, j'ai redimensionné le raid, puis le filesystem etc. Pendant un moment, il plantait au démarrage avec un shell sur l'initramfs car il ne trouvait pas la partition qu'il devait monter, en effet, en tapant un mdadm -As dans le shell initramfs, il indiquait qu'il ne trouvait pas les périphérique associé. En effet, les UUID avaient changé.

Maintenant, ca dépasse cette étape, par contre, l'initramfs plante apres

Begin : running /scripts/init-bottom ...

Done.

Je ne sais pas où exactement, ni pourquoi ... J'ai pu afficher ce message en virant l'option "quiet" dans le grub.cfg

[fabien29200]

Tu n'as pas plus d'infos sur ta machine virtualbox ?

[16ar]

J'ai modifié le script /init dans l'initramfs pour rajouter du log, en fait, ca ne fait rien apres avoir lancé :

exec run-init /root /sbin/init </root/dev/console >/root 2>&1

le curseur ne bouge plus et rien ne se fait

Et la, j'ai un peu cherché sur LFS et je n'ai pas trouvé grand chose.

1. je ne sais pas ou se trouvent les sources de run-init, ni meme si c'est un script, ou un programme c, ou si c'est une commande du shell ...

2. comme ca n'affiche rien ensuite, je pense que le /sbin/init ne se lance pas bien ou autre, mais je ne peux rien voir, je ne sais pas si je peux passer des arguments au init pour afficher sa progression ...

[16ar]

Bon, j'ai regenéré le grub.cfg en modifiant le /etc/default/grub en mettant ca :

GRUB_CMDLINE_LINUX_DEFAULT="break=init"

En redémarrant, il me stoppe juste avant le exec run-init

Du coup, je l'ai lancé à la main dans le shell (en vérifiant bien que mon FS / soit bien dans le repertoire /root (j'ai du monter temporairement /proc (mount -t proc proc /proc) sur le initramfs pour lancer un "mount" pour voir les partitions montées, puis je l'ai démonté (umount /proc)).

exec run-init /root /sbin/init --verbose

la c'a m'affiche :

init: missing runlevel

Try 'init --help' for more information.

Et ensuite, j'ai l'impression que ca lance le exec run-init contenu dans le script /init du initramfs, sauf que la, j'ai des erreurs indiquée :

/init: line 282: can't open /root/dev/console: no such file[...] Kernel Panic - not syncing: Attempted to kill init[...] Pid: 1, comm: init Tainted: G        W 2.6.32-37-server #81-Ubuntu[...] Call Trace:[...] [(addresse memoire)] panic[...] [(addresse memoire)] forget_original_parent[...] [(addresse memoire)] ? put_files_struct[...] [(addresse memoire)] exit_notify[...] [(addresse memoire)] do_exit[...] [(addresse memoire)] do_group_exit[...] [(addresse memoire)] sys_exit_group[...] [(addresse memoire)] system_call_fastpath

Vive les VM pour pouvoir copier ce genre de message, mais je ne le ferai pas 2 fois Mais ca pourra surement aider quelqu'un plus tard

Donc je vais surement virer des parametre dans le script /init du initramfs et deja vérifier si /root/dev/console existe ... Je pense que je vais continuer a nager ...

A vrai dire, je ne comprends pas ce que fait cette redirection </root/dev/console vers le processus init ...

[16ar]

bon, a priori, run-init est un utilitaire de klibc. Il se trouve dans /bin/run-init dans l'initramfs, ensuite, il se trouve sur mon FS / dans /root/usr/lib/klibc/bin/run-init.

[16ar]

Donc je vais surement virer des parametre dans le script /init du initramfs et deja vérifier si /root/dev/console existe ... Je pense que je vais continuer a nager ...

A vrai dire, je ne comprends pas ce que fait cette redirection </root/dev/console vers le processus init ...

/root/dev/console existe bien

j'ai supprime les lignes dans le /init du initramfs qui lancent le exec run-init blabla et celle qui lance le panic si le run-init n'a pas reussi.

j'ai mis un break=init dans mon grub.cfg, du coup ca m'ouvre une console dans l'initramfs juste avant de lancer le run-init (que j'ai desactive)

ensuite je lance le run-init a la main

exec run-init /root /sbin/init --verbose 1

et ca se gauffre pareil

ca me semble assez proche de ca : http://ubuntuforums.org/showthread.php?t=1702818

sauf que pas de reelle reponse, ca s'est regle tout seul.

De mon cote, j'ai vu qu'upstart pouvait etre une cause de soucis en tant que remplacant d'init, du coup il fallait peut etre le patcher :

http://linux-vserver.org/Upstart_issues#Notes_for_older_kernels

J'avais eu l'erreur du : init: missing runlevel

Au final, ca n'a pas marche non plus.

Je sens une pointe de desespoir en moi (j'ai passe la journee dessus...)

[fabien29200]

Tu as fait quoi exactement pour mettre à jour ton initrd ?

[16ar]

Tu as fait quoi exactement pour mettre à jour ton initrd ?

j'ai lance update-initramfs -k all -u

Et ce que j'avais modifie dedans ne se limitait qu'a avoir ajoute des echo pour savoir ou ca se gauffrait, puis avoir commente la ligne du exec run-init puis la ligne du panic.

J'ai regarde les sources de run-init , elle n'ont pas change depuis 2006 qusiment a part pour une verification que l'initramfs possede bien un /init avant de continuer. Or c'est mon cas, donc je ne suis pas cense etre impacte.

Franchement je ne sais pas ce qui deconne et c'est frustrant !

D'ailleurs, quand tu parles d'initrd, tu parles bien de l'initramfs ?

[fabien29200]

A vrai dire, je ne suis jamais allé aussi loin que toi.

Moi j'avais fait une migration de disques durs. J'avais changé les 2 disques par 2 nouveaux plus grands. Vu que je ne voulais pas réinstaller le système (Xubuntu LTS), j'avais recréer un RAID 1 avec mdadm. Ensuite, j'avais recopié les fichiers originaux dans le nouveaux RAID (vive cp -a).

Après, j'ai pas mal galéré sur les UUID pour finir par comprendre que mdadm gérait aussi ses UUID indépendamment des systèmes de fichiers. Du coup, j'avais remis d'équerre le fichier /etc/mdadm.conf. Mais ça ne suffisait pas pour booter, il fallait le répercuter dans l'initrd qui en a une copie.

Par contre, je me suis pas amusé à toucher l'initrd, j'ai chrooté le système en faisant :

livecd# mount /dev/md0 /mnt/ubuntu

livecd# mount -t proc none /mnt/ubuntu/proc

livecd# mount -o bind /dev /mnt/ubuntu/dev

livecd# chroot /mnt/ubuntu /bin/bash

Et ensuite, un coup d'update-grub qui revérifie ta conf grub et recrée tout seul l'initrd comme un grand (avec le nouvel /etc/mdadm.conf) :

chroot# update-grub

Et là, ça marchait bien après.

[16ar]

Ah oui, quasiment le meme scenario :)

Sauf que chez moi, ca ne marche pas, et ca pourrait etre upstart.

Car vraiment , le systeme / est bien monte sur /root. /root/dev/console existe bien, etc. Je ne vois vraiment pas ce qui deconne.

Je pense que je vais patcher run-init et foutre des traces et voir ou ca merde ...

Et dire que la, c'est juste sur ma virtualbox. A pres je risque de me taper les meme merde avec ma dedibox, sauf que je ne pourrai pas debugger comme ca. Mais je partirai du postulat que ca sera le meme probleme. On verra

[16ar]

C'était bien upstart ...

Sur une debian, pas de soucis...

En fait, si, mais pour une autre partie (chiffrement d'une partition avec /etc/crypttab, initramfs-tools n'arrive pas trouver la bonnes partition avec mdadm...)