Passage au noyau 3.9, boot impossible car RAID non reconnu

Support Debian
#1

Bonjour,

Depuis quelques jours, ma machine personnelle a des problèmes de démarrage.

Ma machine dispose d’un petit disque indépendant sur lequel se trouve le
/boot, et d’un ensemble de 3 disques en RAID 5 sur lequel se trouve un
groupe de volume LVM, lui-même contenant toutes les partitions classques
(/, /usr, …). Cette configuration est en place depuis plusieurs années et
a toujours bien fonctionné.

Si je la laisse partir sur le nouveau noyau par défaut de Debian/Jessie
(3.9-1-amd64), elle se bloque tout de suite n’arrivant pas à trouver les
disques RAID. J’ai un message du genre :

« mdadm: no devices listed in conf file were found »

Ce message est affiché très tôt dans la séquence d’amorçage, alors que le
système n’a manifestement pu que lire le noyau et le initramfs depuis la
partition /boot (qui est bien entendu hors du raid). Les conséquences sont
immédiates : n’arrivant donc pas à trouver la grappe de disques raid, il n’a
pas le device /dev/md0, donc il ne trouve pas le lvm qui est dessus et contient
le groupe de volume vg00, donc il ne trouve aucune partition (/, /usr …). Évidemment,
il ne peut pas aller très loin dans ces conditions … La séquence s’interromp
donc immédiatement, et je me retouve avec une invite de commande busybox. Malheureusement,
je ne peux rien en faire car mon clavier ne répond plus (alors qu’il fonctionnait tant
que j’étais sous le bios par exemple) … Je suis obliger d’éteindre électriquement la
machine.

Si par contre je sélectionne dans le menu grub l’ancien noyau toujours
en place (3.2.0-4-amd64), tout démarre parfaitement. Dans les premiers instants du
démarrage, j’ai un message bien plus normal concernant le raid, un truc du genre
(de mémoire) :

« /dev/md/0 has been started with 3 drives »

J’ai vérifié les fichiers /etc/default/mdadm et /etc/mdadm/mdadm.conf à la fois sous ma
partition / une fois que la machine est démarrée avec l’ancien noyau, mais également
dans les partitions temporaires contenues dans les deux initramfs correspondant aux deux
noyaux (et qui ont été créés tout à fait normalement par un update-initramfs). Dans tous
les cas, la configuration raid paraît normale et complète.contient bien les options de
démarrage automatique, le fichier /etc/mdadm/mdadm.conf contient bien l’UUID de la
grappe de disques.

J’ai tenté de refaire plusieurs fois le initramfs, mais les problèmes persistent.

Évidemment, comme le problème se situe avant l’accès aux disques
physiques, quand j’amorce mon système sur l’ancien noyau, je ne trouve
dans le /var/log que des informations sur les démarrages du 3.2.0.
Toutes les tentatives de démarrage sur le 3.9 échouent et ne laissent
aucune trace dans le /var/log puisqu’il est sur une partition non trouvée …

J’ai comparé les fichiers /boot/config-3.2.0-4-amd64 et
/boot/config-3.9-1-amd64, et la seule chose semblant liée au RAID est
que la version 3.2 a une ligne : CONFIG_MULTICORE_RAID456 is not set. À
la limite, j’aurais donc dit que c’est plutôt le noyau 3.2 qui ne
devrait pas fonctionner.

J’ai décompressé et dé-cpioisé les deux initramfs pour comparer les
fichiers de configuration. Le /etc/mdadm/mdadm.conf est strictement
identique dans les deux cas. Les modules pour les pilotes raid sont
présents dans les deux cas sous
/lib/modules//kernel/drivers/md. Les fichiers
/lib/modprobe.d/aliases.conf sont rigoureusement identiques dans les
deux cas. Les fichiers modules.aliases ont des petites différences, il y
a quelques lignes en plus dans la version 3.9:

root@lehrin:/tmp# diff 3.2/lib/modules/3.2.0-4-amd64/modules.alias
3.9/lib/modules/3.9-1-amd64/modules.alias
1a2

alias fs-ext4 ext4
3a5,7
alias fs-fuseblk fuse
alias fs-fuse fuse
alias fs-fusectl fuse
179a184,185
alias pci:v00008086d00002827svsdbcsci* ahci
alias pci:v00008086d00002823svsdbcsci* ahci
root@lehrin:/tmp#

Il y a aussi quelques différences dans les fichiers modules.order et
modules.symbols, mais rien qui ne semble expliquer mon problème.

Je ne comprends pas pourquoi mon noyau 3.9 n’arrive pas à ouvrir le
/dev/md0, tout semble correctement déclaré, le noyau semble avoir tous
les modules nécessaires pour activer le raid, et tout marche parfaitement
avec l’autre noyau.

Un collègue m’a récemment indiqué avoir eu des problèmes avec le noyau
3.9 (une histoire d’UUID qui avait changé bizarrement, avec juste deux
chiffres hexadécimaux inversés à la fin). Le fichier /etc/mdadm/mdadm.conf
déclare la grappe par une ligne contenant l’UUID plus un nom :

ARRAY /dev/md/0 metadata=1.2 UUID= name=:0

J’ai tenté de reconstruire les initramfs en retirant l’UUID au cas où le problème
rapporté par mon collègue expliquerait que le raid ne soit pas trouvé, mais d’une
part update-initramfs m’a affiché un avertissement disant que cette grappe raid
active n’était pas déclarée et donc risquait d’empêcher le démarrage, d’autre part
quand j’ai tenté malgré tout le démarrage, j’ai bien entendu eu de nouveau les
mêmes problèmes.

Si je regarde les disques avec fdisk, j’observe ceci :

(lehrin) luc% sudo fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa93e0ab4

Device Boot Start End Blocks Id System
/dev/sdd1 63 1953520064 976760001 da Non-FS data

C’est à dire que l’ID des partitions utilisées dans la grappe raid est
positionné à la valeur « da » qui correspond à Non-FS data au lieu
d’être à « fd » qui correspondrait à Linux RAID autodetect. La même
valeur est utilisée pour les trois disques de la grappe (c’est du RAID 5).

Pensez-vous que ceci puisse être la raison de mon problème, et surtout
pensez-vous que je puisse changer l’id des partitions pour la mettre à «
fd » sans risque ? Puis-je le faire petit à petit, en désactivant un
disque, changeant son id, reconnectant le disque, synchronisant la
grappe et recommençant pour les disques suivants ? Quelle serait la
liste de commandes à lancer pour ce faire ?

#2

Ton kernel est peut étre trop en avance sur le paquet de gestion du RAID (mdammin et autres).
essaie de les prendre dans SID.
C’est un peu chaotique la testing en ce moment, ça bouge par à coup.

#3

Je viens de tester avec mdadm provenant de sid, le problème subsiste.
Après l’installation, les fichiers initramfs ont bien été regénérés correctement
et contiennent donc bien la version à jour de mdadm.

J’ai également tenté de mettre un noyau plus récent (3.10-rc7) et cela ne marche
pas plus. J’observe toujours l’erreur :

mdadm: No devices listed in conf file were found.

Le plus embêtant dans cette erreur est qu’elle intervient tellement tôt que
je n’ai aucun moyen de récupérer la moindre information sur le problème.

#4

J’aurais bien suggéré de vérifier dans le shell de secours de l’initramfs si les disques sont bien reconnus, mais si le clavier n’est pas opérationnel ça va gêner un peu… D’ailleurs à mon avis il faudrait se pencher sur ce problème-là aussi. Même les “magic sysrq keys” sont sans effet ? (sinon il y a l’option d’envoyer la console sur un terminal série déporté mais ça commence à être lourd)

#5

Les magic sysrq keys ne fonctionnent pas …
En fait, même le fait de presser le verrouillage numérique des touches ne change pas l’état de la led clavier …
D’accord, c’est un clavier USB bluetooth, mais quand même le BIOS est capable de le reconnaître, j’aurais espéré que busybox et le noyau normal y arrivent …

J’ai tout de même trouvé un palliatif à ce problème là : j’avais un vieux clavier filaire avec un port PS2, et comme ma carte mère dispose de la connectique correspondante, j’ai pû le brancher. Miracle ! Ce clavier répond.

Je suis en train de chercher sous busybox (heureusement que j’ai un portable à côté pour rester connecté pendant mes recherches).

J’ai assez peu de choses disponibles dans cet environnement (par exemple pas de fdisk). J’ai tout de même quelques commandes, et ai ainsi réussi à consulter les messages de boot. Je vois bien des

sda : sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sdc : sdc1
sd 2:0:0:0: [sdc] Attached SCSI disk
sdd : sdd1
sd 3:0:0:0: [sdd] Attached SCSI disk
sdb : sdb1
sd 0:0:0:0: [sdb] Attached SCSI disk

Donc les disques sont reconnus et les partitions sont vues. la grappe raid est normalement constituée de sdb1, sdc1, sdd1 (le /boot est sur le sda1 et le sba2 est inutilisé.

Si je lance :

mdadm --autodetect

La commande ne retourne rien. Si par contre je lance :

mdadm --assemble --scan

J’obtiens la réponse :

mdadm: /dev/md/0 has been started with 3 drives.

Je peux ensuite lancer :

vgchange -a y

et le système réplique par :

5 logical volume(s) in volume group “vg00” now active
3 logical volume(s) in volume group “vg01” now active

Bon, pour l’instant je n’arrive toujours pas à monter les partitions correspondantes :

(initramfs) ls /dev/mapper
control vg00-spare vg00-usr vg01-archive vg01-spare
vg00-root vg00-swap vg00-var vg01-home
(initramfs) mkdir /mnt
(initramfs) mount /dev/mapper/vg00-root /mnt
mount: mounting /dev/mapper/vg00-root on /mnt failed: No such file or directory

J’ai vérifié plusieurs fois, /dev/mapper/vg00-root et /mnt existent bien. Je continue mes investigations …

#6

J’ai fini par démarrer la machine sous le noyau 3.9, mais cela nécessite des incantations proches de la magie noire, et c’est pour l’instant manuel.

Le problème n’est pas uniquement lié au raid, lvm bloque en fait en amont. Il me semble que tous les deux sont basés sur dmsetup, il y a donc tout de même une corrélation.

Je croyais que mes partitions /, /usr etaient sur le raid, mais en fait non, elles sont sur le petit disque. Le découpage correct est donc :

[ul]/dev/sda1 -> /boot[/ul]
[ul]/dev/sda2 -> volume physique pour lvm, contenant le groupe de volume vg00[/ul]
[ul]/dev/sd{bcd}1 -> grappe de trois partitions en raid5, , contenant le groupe de volume vg01[/ul]

Les partitions système (/, /usr, /var …) sont dans vg00, les partitions de données (/home, /archive) étant dans vg01 en raid.

Bref, sans le raid je devrais être capable de démarrer avec le seul disque /dev/sda.

Pour démarrer, il suffit que vg00 soit reconnu. J’arrive à le faire manuellement en gardant mon vieux clavier connecté sur la carte mère et en lançant l’unique commande

depuis initramfs puis en faisant exit pour laisser la séquence de démarrage reprendre son cours. Une fois le système complètement en place, je peux récupérer tous les messages de démarrage ; il n’y a aucun indice de ce qui se passe mal. Voici un extrait de ces messages

[    1.692087]  sda: sda1 sda2
[    1.692600] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.700081]  sdd: sdd1
[    1.700438] sd 3:0:0:0: [sdd] Attached SCSI disk
[    1.700690]  sdc: sdc1
[    1.701003] sd 2:0:0:0: [sdc] Attached SCSI disk
[    1.702848]  sdb: sdb1
[    1.703214] sd 1:0:0:0: [sdb] Attached SCSI disk
[    1.834460] tsc: Refined TSC clocksource calibration: 2204.693 MHz
[    1.834467] Switching to clocksource tsc
[   39.598720] bio: create slab <bio-1> at 1
[   42.677135] PM: Starting manual resume from disk
[   42.677140] PM: Hibernation image partition 253:3 present
[   42.677142] PM: Looking for hibernation image.
[   42.677442] PM: Image not found (code -22)
[   42.677446] PM: Hibernation image not present or could not be loaded.

On voit ici que j’ai mis entre 35 et 40 secondes pour reprendre la main sous initramfs, lancer le vgchange puis laisser la machine continuer. Rien ne montre pourquoi vg00 n’a pas été détecté.

J’ai tenté de mettre un lvm2 plus récent à partir de sid et de refaire le initramfs, cela n’a rien donné.

Je vais chercher s’il m’est possible de changer les scripts présents dans le initramfs pour ajouter une commande vgchange qui serait lancée automatiquement juste après la détection des disques.

#7

C’est bizarre ton problème. Je suis passé il y a quelques jours au 3.9, et le RAID est bien reconnu (2 disques seulement)

#8

Le problème n’est toujours pas complètement résolu, mais j’ai fait quelques progrès.

Tout d’abord en ce qui concerne le clavier inutilisable depuis le busybox dans le initramfs, c’était un problème de pilotes non installés. Cela ressemblait fortement à l’anomalie : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701953, j’ai donc ajouté à la main de le fichier /etc/initramfs-tools/modules la liste de modules suivante:

[ul]ehci_pci
usbcore
usb_common
xhci_hcd
uhci_hcd
ehci_hcd
ohci_hcd
usbhid
hid_generic[/ul]

J’ai ensuite regénéré normalement mon initramfs et le clavier marche sous busybox.

En ce qui concerne le groupe de volume vg00 inaccessible, l’erreur se produit au moment du lancement de la commande :

Cette commande est lancée depuis le script local-top/lvm2.

J’ai également remarqué que lors de la tentative de boot avortée sur le noyau 3.9, je vois d’abord les messages de lvm concernant le vg00 introuvable, puis une série de messages du genre :

ata1: softreset failed (device not ready)
ata2: softreset failed (device not ready)
ata3: softreset failed (device not ready)
ata4: softreset failed (device not ready)

puis j’obtiens l’invite de commande busybox et là la commande vgchange -ay marche. Par contre, lors du démarrage avec le noyau 3.2 qui marche, les messages “ata” apparaissent avant la tentative de lancement lvm, et elle fonctionne toute seule.

Ceci m’incite à penser que dans la séquence de boot, quelque chose lié aux disques est lancé dans un cas avant lvm et du coup les disques sont dans l’état nécessaire pour que lvm retrouve ses billes, et dans l’autre cas lancé après lvm et du coup lvm échoue la première fois mais fonctionne quand je récupère la main sous initramfs car entre-temps le nécessaire a finalement été lancé.

Qu’en pensez-vous ? Quelqu’un saurait-il ce qui peut être en cause et comment je pourrais le déplacer avant lvm (j’imagine qu’il faudrait changer les lignes concernant les prereqs au début du script lvm2 de local-top).

#9

y aurait il un air de famille avec ça ?
bugs.debian.org/cgi-bin/bugreport.cgi?bug=251905

nota: pas de LVM chez moi, donc peut étre pour ça que je n’ai pas ce problème.

#10

[quote=“piratebab”]y aurait il un air de famille avec ça ?
bugs.debian.org/cgi-bin/bugreport.cgi?bug=251905

nota: pas de LVM chez moi, donc peut étre pour ça que je n’ai pas ce problème.[/quote]

Je n’ai pas l’impression qu’il s’agisse du même problème. D’une part ce fil est très vieux (2004) et donc beaucoup de choses ont changé depuis lors, d’autre part ce ne sont ni grub, ni partd ni l’installation qui posent problème, mais le démarrage et
uniquement sous un noyau particulier.

#11

Bonjour,

J’ai eu le même soucis que toi, et je l’ai résolu par l’option ‘rootdelay’ du noyau.

Pour cela, j’ai modifié GRUB et ajouté ‘rootdelay=10’ sur la ligne ‘linux’.

Tu pourras par la suite réduite le délai en testant que ton noyau boote toujours ton raid. Dans mon cas, je l’ai fixé a 2 secondes.

#12

Je n’ai pas encore testé le rootdelay, mais j’ai trouvé un palliatif.

Le problème est que lorsque scripts/local-top/lvm2 est lancé, /dev/disk n’est pas encore apparu. La commande lvm lvchange présente dans ce script échoue donc. Quelques secondes plus tard, /dev/disk apparait, mais en fait on est déjà sorti de scripts/local-top/lvm2 (et en fait on est même sorti de tous les scripts sous local-top. On se situe à ce moment là dans scripts/local, et plus précisément dans la fonction pre_mountroot qui justement est en train de boucler jusqu’au ROOTDELAY, avec un maximum de 30 secondes si ROOTDELAY n’a pas été initialisé. Je ne pense donc pas que changer le rootdelay changera quelque chose, car j’ai l’impression qu’il agit alors qu’il est déjà trop tard (mais peut-être est-il aussi utilisé à un autre endroit, je n’ai pas encore vérifié).

Pour garantir que la commande lvm lvchange ne soit lancée que quand /dev/disk est disponible, j’ai ajouté dans scripts/local-top/lvm2 les lignes suivantes, juste avant la commande en question :

icount=0
while [ ! -e /dev/disk/by-path ] && [ $icount -lt 300 ] ; do
    /bin/sleep 0.1
    icount=$(( $icount + 1))
done

Ces lignes sont largement inspirées de la boucle du ROOTDELAY située dans scripts/local.

Il semblerait que pour mon disque, la boucle soit exécutée deux ou trois fois. Dès que /dev/disk apparaît, la boucle s’achève et la commande lvm lvchange marche parfaitement.

Je ne sais par contre toujours pas pourquoi le noyau 3.2.0 marchait, car les même scripts lvm2 tournaient. Je me demande si c’est le noyau qui va plus vite maintenant ou qui fait des trucs plus tôt, ce qui ne donne pas le temps au disque de se configurer et d’envoyer son état.

Je vais très probablement ouvrir un rapport de bogue sur lvm2 décrivant le problème et le palliatif que j’ai trouvé. Je suis certain qu’ils trouveront une solution plus propre que la mienne.

J’ai une dernière question : comment puis-je marquer ce problème comme résolu dans ce forum ? Je ne trouve pas de case à cocher pour cela.

Merci à tous ceux qui ont contribué à cette discussion.

#13

Pour information, j’ai ouvert la rapport d’anomalie suivant :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715184

#14

misty soul: Merci pour tes recherches, je rencontre exactement ce problème.
Après une migration d’une debian 6 en 32bits de Citrix XEN vers VMWARE, j’arrive au prompt initramfs et un message m’indique que mes partitions LVM ne sont pas visibles (Et idem pour une Debian 7 en 64bits)
Après un “lvm vgchange -ay” et et un “exit”, le système démarre sans problème.
Par contre, à chaque reboot, même histoire.
Et je n’arrive pas à mettre à jour initramfs avec la boucle que tu as créée.
Comment fait-on stp?

#15

Voici la méthode que j’utilise maintenant, légèrement améliorée depuis que j’avais posté les derniers messages.

Dans le répertoire /etc/initramfs-tools/scripts/init-top, j’ai créé un script que j’ai nommé wait-for-disks, appartenant au super-utilisateur root et ayant des droits d’exécution :

root@lehrin:~# ls -l /etc/initramfs-tools/scripts/init-top/wait-for-disks -rwxr-xr-x 1 root root 438 juil. 8 16:49 /etc/initramfs-tools/scripts/init-top/wait-for-disks root@lehrin:~#

Le contenu de ce script est le suivant :

[code]root@lehrin:~# cat /etc/initramfs-tools/scripts/init-top/wait-for-disks
#!/bin/sh

prereqs()
{
# this part has been borrowed from the script local-top/cryptroot
# Make sure that we are run last in init-top
for req in $(dirname $0)/; do
script=${req##/}
if [ $script != $(basename $0) ]; then
echo $script
fi
done
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

icount=0
while [ ! -e /dev/disk/by-path ] && [ $icount -lt 100 ] ; do
/bin/sleep 0.1
icount=$(( $icount + 1))
done

exit 0
root@lehrin:~#[/code]

D’une façon générale, les sous-répertoires de /etc/initramfs-tools/scripts/ sont prévus pour contenir les scripts propres à l’utilisateur. Ces scripts sont automatiquement ajoutés aux scripts prédéfinis par le système lors de la création du disque ram initial. Les scripts prédéfinis sont quant à eux dans les sous-répertoires de /usr/share/initramfs-tools/scripts/, il est inutile de les modifier avec la méthode actuelle.

Lorsque le script wait-for-disks est présent dans le répertoire /etc/initramfs-tools/scripts/init-top, on passe la commande update-initramfs comme suit :

root@lehrin:~# update-initramfs -k all -u update-initramfs: Generating /boot/initrd.img-3.10-2-amd64 root@lehrin:~#

Cette commande crée le ramdisk et l’installe dans le répertoire /boot, où il sera utilisé pour tous les démarrages suivants.

L’intérêt de cette méthode est que l’on ne touche pas aux scripts prédéfinis. Ceci implique que si l’outil update-initramfs est mis à jour, on ne perd pas ses modifications qui sont dans un script à part, à l’abri. D’autre part, on laisse ce script dans le répertoire /etc/initramfs-tools/scripts/init-top. Ceci implique que si un nouveau noyau est publié, alors la commande update-initramfs sera lancée automatiquement par le système de gestion des paquets (que ce soit apt, aptitude ou n’importe quel autre système compatible), et ce lancement automatique mettra en place le script pour ce nouveau noyau.

J’espère que c’est assez clair et que cela marchera pour toi.

#16

Merci! Tu devrais faire prof! Tes explications sont super claires et faciles à comprendre.

Bon, mais en attendant, ça ne marche pas pour moi.
Voici quelques détails:
/dev/sda1 => /boot
/dev/sdb1 => LVM avec /, /home, swap…
LVM découpé en 1 vg (vg01) et plusieurs LV

L’installation de cette debian a été faite sur un Citrix XEN.
Migration vers VMWare ESXi 5.1 => OK
Démarrage sur ESXi NOOK parce que /dev/vg01/slash does not exist

Je me retrouve donc devant un prompt “initramfs” ou je tape “vgchange -ay”. Tous mes LV sont trouvés.
Puis je tape “exit” et le boot suit son cours.

J’ai mis ton script, et updaté l’initramfs comme tu l’as indiqué, et ça n’a rien changé.
J’ai modifié ton script en mettant “/dev/vg01/by-path” au lieu de “/dev/disk/by-path”, mais ça ne change rien non plus…

Si tu as un peu de temps à me consacrer, ça serait super cool! :023

#17

Il m’arrive effectivement d’enseigner, et j’aime bien ça. J’interviens en tant que vacataire dans une grande école, pour des élèves ingénieurs en 2ème et 3ème année, mais jusqu’à cette année je n’intervenais pas en informatique.

Je n’ai guère d’idées our t’aider, mis à part t’indiquer la démarche que j’ai suivie de mon côté pour résoudre le problème. C’est un peu laborieux car cela implique un redémarrage à chaque essai, ce qui est long.

Tu peux tenter de suivre le processus de démarrage en insérant des commandes “echo” dans les scripts prédéfinis, ceux qui sont sous /usr/share/initramfs-tools/scripts/. Pour ma part j’avais à la fin des floppées de “echo coucou 1”, “echo coucou 2” … C’est assez artisanal mais instructif. Après chaque modification d’un des scripts, il faut bien entendu regénérer le disque ram par une commande update-initramfs avant de redémarrer.

Tu peux aussi tenter un truc un peu sauvage, qui consisterait à forcer une commande “vgchange -ay”. Il faut trouver le bon endroit pour la mettre. Je ne sais pas si le script wait-for-disks est le bon endroit, mais c’est possible (à la fin du script alors, pour être sûr que les disques sont disponibles au moment où la commande est lancée). Peut-être faut-il mettre cette commande un peu plus tard dans la séquence de démarrage et donc dans un autre script. Tu peux éventuellement commencer en modifiant les scripts prédéfinis pour trouver le bon endroit, et une fois que cela marchera (si cela marche), tu pourras dans un second temps trouver une manière plus propre avec un script personnalisé dans /etc, pour éviter de perdre tes modifications à la mise à jour suivante de initramfs-tools.

#18

Gagné!!!
J’ai créé un script /etc/initramfs-tools/scripts/init-top/activate_lvm dont voici le contenu:

#!/bin/sh


prereqs()
{
   # this part has been borrowed from the script local-top/cryptroot
   # Make sure that we are run last in init-top
   for req in $(dirname $0)/*; do
      script=${req##*/}
      if [ $script != $(basename $0) ]; then
         echo $script
      fi
   done
}

case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac

# Activation des LVM sinon, pas de boot!
lvm vgchange -ay;

exit 0

Et après un petit

Et la machine boote toute seule!

Grand Merci M’sieur le professeur! :clap:

#19

Et rebelote avec une Debian 6.
Ca marche nikel avec une Debian 7 x64, mais pas avec une debian 6 x32.
Nouveau message: /proc/misc: no entry for device-mapper found
Il manque un module j’ai l’impression…

Malgré la boucle d’attente, le “lvm vgchange” arrive trop tôt…

J’ai modifié /etc/initramfs-tools/modules en rajoutant sd_mod et dm_mod, mais ça ne change rien…

Help please?

#20

C’est bon, trouvé!
J’ai rajouté “modprobe dm_mod” avant “lvm vgchange -ay” dans mon script.
:041