# [udev/kernel]besoin de conseils suite à vacances...

## DuF

Hello tout le monde,

Bon, déjà je suis totalement responsable de ce qui m'arrive...

J'ai eu la brillante idée de faire la mise à jour d'udev qui nécessitait l'option devtmpfs dans le noyau la nuit (vers 3h) précédant mon départ en vacances pour une contrée lointaine. J'étais persuadé d'avoir ajouté l'option ainsi que d'avoir vérifié après compilation que l'option était bien dans le noyau.

Vous vous en doutez, ça n'a pas loupé, mon ordinateur ne démarre plus comme il faut...

Pour éviter d'empirer les choses, je viens écouter vos conseils pour une solution simple et efficace permettant de réparer la chose.

Je vous expose ce à quoi j'ai pensé  :

- booter sur le liveCD gentoo (de fin décembre)

- copier le noyau et initramfs du liveCD sur ma partition /boot

Cela vous parait-il jouable, voyez-vous mieux à faire ?

Les contraintes que j'y vois concernent le fait que je suis en raid1 (même pour /boot) et que j'aimerai éviter que le liveCD me pourrisse mes UUID (surtout pour mon gros volume de données). A la limite si c'est la seule solution je prends quand même, mais la dernière fois que j'ai reconstruit ça a pris beaucoup beaucoup de temps   :Sad: 

Là pour le coup, j'aimerai monter mes volumes raid1 à partir du liveCD le plus proprement possible, comment procéderiez-vous ?

N'hésitez pas à me poser des questions si je n'ai pas été clair, pour l'instant je ne suis pas encore bien dans le coup après mon retour de vacances   :Laughing: 

DuF

----------

## xaviermiller

Bonjour,

Une option plus simple serait de booter un live CD, de chrooter ta Gentoo, d'ajouter l'option du noyau, de le recompiler, et de réparer le reste (/usr séparé, ...).

----------

## boozo

L'est pas bien réveillé le Xavier... il est full raid et le risque est de mettre le brin dans les array avec un livecd   :Wink: 

Je ne suis pas expérimenté en récupération de raid en carafe donc je ne me prononce pas réellement sur la méthode la moins risquée mais n'est-il pas possible de créer extérieurement un initrd avec mdadm inclu qui monterait le(s) raid au plus tôt avant prise en charge du /root afin de pouvoir recompiler la quenelle ?

----------

## xaviermiller

Pourquoi serait-ce plus compliqué avec du RAID ?

----------

## boozo

Ben... je ne suis pas suis un sujet maîtrisé loin de là mais ce que j'en comprends/déduit (peut-être à tord excusez mon ignorance en la matière) c'est qu'il y a eu un crash/hard reboot à cause de la màj udev mal négociée et donc que le(s) raid nécessite de réaliser la maintenance pour laquelle il est là.

Le pb me semble être d'arriver a lire les bonnes infos/metadata pour celà (blkid?) à partir du LIvecd non ?

(ça ne ressemblerait pas à ça le pb p.e. ?)

----------

## DuF

Merci pour vos réponses et effectivement j'avais complètement pas pensé au fait de booter le liveCD pour refaire ma compilation en chroot....   :Confused:  Par contre je ne dois pas avoir de trucs à réparer, j'ai pas de /usr séparé.

Sinon pour l'instant mon raid va bien, il est marqué clean donc j'ai pas d'opération de maintenance à réaliser, je souhaite éviter d'en faire (pas que ce soit chiant mais surtout que c'est long). Et surtout la dernière fois que je l'ai monté depuis un liveCD, je ne m'étais pas rendu compte que j'avais monté le raid avec un seul membre, d'où la resynchro derrière qui avait pris du temps. Et surtout au niveau du liveCD j'ai pas vu comment monter les volumes (ou alors faut que je créé les noeuds avec mknod).

@+

----------

## GentooUser@Clubic

C'est du raid hardware ou mdadm ?

Perso pour le dépannage dans ce genre d’environnements j'utilise RIPLinux http://www.tux.org/pub/people/kent-robotti/looplinux/rip/

Y'a normalement tout pour assembler proprement ton array raid dedans.

----------

## boozo

ah?! raté ! interprétation trop avancée   :Laughing: 

Je ne sais pas s'il y a une cmdline ou option spécifique via les livecd... j'aurai tendance à penser que oui mais c'est vrai que je n'ai pas vu cette hypothèse/CU détaillée dans les how-to du reste ; notamment celui-ci que j'avais pourtant trouvé très complêt avant que je ne me passe _définitivement_(?) d'udev   :Mr. Green:  - mais vais chercher pour ma culture ^^ -

----------

## DuF

C'est du pur mdadm, mais comme l'indique "XavierMiller" sans doute que le plus simple est juste de reprendre le travail pour chrooter proprement et faire les compilations de noyau dans cet environnement.

Dernière question concernant mdadm depuis le liveCD histoire d'être sûr que le raid restera clean, si je fais des trucs genre : 

```

livecd ~ # mknod /dev/md1 b 9 1

livecd ~ # mdadm --assemble /dev/md1 /dev/sda1 /dev/sdb1

```

A priori ça devrait le faire ça ?

EDIT : Je viens peut être de comprendre ce qui a merdé suite à ton lien Boozo car ils indiquent  *Quote:*   

> If you are using kernel raid auto assembly, turn it off

 Je pense que je l'avais laissé.

@+

----------

## boozo

A ce que j'en ai lu, il semble que l'auto-assemblage des arrays est automatique depuis la plupart des Livecd (sysrescuecd en tout cas) en effet.

Pour ta procédure, attends peut-être un chouilla l'avis des autres car je ne préfère pas m'avancer vu mon manque d'expérience avec ces choses mais auquel cas j'ai vu un exemple de méthode ici qui semble coller en cas de renommage.   :Smile: 

----------

## DuF

Je ne pourrai vérifier que ce soir mais j'ai pas l'impression que ce soit le cas du dernier liveCD (en version DVD), de toute façon je vais tenter un assemblage automatique et je verrai bien ce qu'il me dira (mais j'ai du mal à croire que ça fonctionne sans les noeuds dans /dev).

@+

----------

## DuF

Petit retour, donc la solution de XavierMiller était la plus simple et rapide même si ayant oublié les noms de mes noeuds j'ai foutu le dawa dans ma configuration (le temps de comprendre et de corriger grub et fstab). L'important c'est que tout va bien et tous les problèmes étaient liés à mes propres erreurs (initiales avec le noyau mal compilé et finale avec les changements sur les arrays).

Au passage je confirme qu'il ne faut pas tenter ce genre de choses la nuit avant un départ en vacances, car j'ai revérifié le noyau que j'avais compilé et l'option que je pensais avoir incluse ne l'était pas....   :Laughing: 

Sinon j'ai voulu en profiter pour modifier mon fstab afin qu'il pointe sur les UUID plutôt que les nœuds /dev/mdx (pour les prochaines où je me mélangerais entre les différents nœuds /dev), mais ce fut un échec. 

J'ai donc une question, pourquoi le UUID différe entre ce que donne blkid et mdadm --detail /dev/mdx ?

----------

## GentooUser@Clubic

 *DuF wrote:*   

> 
> 
> J'ai donc une question, pourquoi le UUID différe entre ce que donne blkid et mdadm --detail /dev/mdx ?

 

blkid retourne l'UUID de ton système de fichiers, mdadm celui de ton array raid. pour fstab il faut l'UUID du système de fichiers.

----------

## DuF

 *GentooUser@Clubic wrote:*   

>  *DuF wrote:*   
> 
> J'ai donc une question, pourquoi le UUID différe entre ce que donne blkid et mdadm --detail /dev/mdx ? 
> 
> blkid retourne l'UUID de ton système de fichiers, mdadm celui de ton array raid. pour fstab il faut l'UUID du système de fichiers.

 

C'est bien ce que j'ai mis mais il n'a pas aimé, à l'init il m'a mis un joli message comme quoi ça lui était inconnu... Je suis donc repassé au /dev/mdx et j'ai revérifié que je n'avais pas fait d'erreurs de typo entre la sortie de blkid et mon fstab. Tant pis, ce n'est pas bien grave et maintenant je sais à quoi correspond l'UUID de mdadm, merci.

----------

