[SQUEEZE] Problème grub : mdadm changement de noyau

g373 · Février 21, 2016, 2:01pm

Salut à tous,

J’ai une Debian avec un noyau xen 3.2.0 j’ai des problèmes sous plusieurs vm lors de l’utilisation de la jvm, j’ai un vieux dump que je ne comprend pas. Mon problème est que je n’ai pas ce problème avec les même vm sous xen mais en noyau 2.6.32-5-xen.

Je met donc la faute sur le noyau xen qui doit poser problème dans les vm (paravirtualisation)

Je décide donc via grub de repartir sur mon ancien noyau pour cette machine (2.6.32-5-xen)

je le sélectionne au boot et là patatra… :

mdadm no devices listed in conf file were found

ALERT /DEV/disk/by-uuid/df366381-0506-4b3b-8d4d-e393696a5866 does not exist

Et je me retrouve dans un busybox… Comment pourrait t’il ne pas trouver mon disque ??

Alors j’ai effectivement j’ai recherché cette erreur, ce n’est pas un problème d’accès ou autre, en effet mes menuentry sont correct et l’UUID du disque est OK :

menuentry 'Debian GNU/Linux, avec Linux 2.6.32-bpo.5-amd64' --class debian --class gnu-linux --class gnu --class os { insmod part_gpt insmod ext2 set root='(hd0,gpt1)' search --no-floppy --fs-uuid --set 92c05f33-db01-4031-a09b-5c09e8ad5549 echo 'Chargement de Linux 2.6.32-bpo.5-amd64 ...' linux /vmlinuz-2.6.32-bpo.5-amd64 root=UUID=df366381-0506-4b3b-8d4d-e393696a5866 ro rootdelay=40 quiet echo 'Chargement du disque mÃ©moire initial ...' initrd /initrd.img-2.6.32-bpo.5-amd64

root@sd-37359:~# blkid /dev/sda4: UUID="MpDirU-Dff1-5hOk-ehUQ-Pyeu-en5E-cTlV3K" TYPE="LVM2_member" /dev/sda1: LABEL="/boot" UUID="92c05f33-db01-4031-a09b-5c09e8ad5549" TYPE="ext4" /dev/sda2: LABEL="/" UUID="df366381-0506-4b3b-8d4d-e393696a5866" TYPE="ext4" /dev/sda3: UUID="4ecec342-9568-4c04-9d74-f0e1f545d221" TYPE="swap"

J’ai lu aussi que p-e les disques mettaient du temps à s’init du coup j’ai rajouter : rootdelay=40 rien ne change, en effet pourquoi ils mettraient plus de temps d’une ligne du grub loader à l’autre ??

Voila où j’en suis. A coté de ça mes VM fonctionne très bien, routing / Masquerading etc c’est juste ce problème de jvm et des kernel…

Si ça parle à quelqu’un…

Merci

etxeberrizahar · Février 21, 2016, 2:01pm

Une partition /boot et une partition racine / sont à l’œuvre comme l’attestent
/vmlinuz-2.6.32* et /initrd.img-2.6.32* en lieu et place de /boot/vmlinuz-2.6.32* /boot/initrd.img-3.6.32*.
boot
/dev/sda1: LABEL="/boot" UUID=“92c05f33-db01-4031-a09b-5c09e8ad5549” TYPE=“ext4”
/, racine
/dev/sda2: LABEL="/" UUID=“df366381-0506-4b3b-8d4d-e393696a5866” TYPE=“ext4”

Dans l’entrée grub, ces partitions se trouvent, semble-t-il, correctement définies ,
set root=’(hd0,gpt1)’ (Notons également le type gpt).
–set 92c05f33-db01-4031-a09b-5c09e8ad5549
contre
root=UUID=df366381-0506-4b3b-8d4d-e393696a5866

Puisque l’UUID de la racine semble coincer, tenter de démarrer en définissant la racine du système à l’ancienne, /dev/sd??.
Remplacer root=UUID=df366381-0506-4b3b-8d4d-e393696a5866 par root=/dev/sda2 dans l’entrée grub. Ne pas modifier /boot défini par UUID , retoucher uniquement la définition de la racine sous la forme /dev/sda2 dans l’entrée de grub.

Si le démarrage se boucle de manière satisfaisante, remettre les initrd.img (ancien et nouveau) à jour puis redémarrer.

update-initramfs -u -k 2.6.32*

update-initramfs -u -k 3.2.0*

g373 · Février 21, 2016, 2:01pm

Ok, tout d’abord merci de ta réponse et de ton aide.

Pour info voici l’entrée par défaut qui me permet de boot sans soucis :

menuentry 'Debian GNU/Linux, with Linux 3.2.0-0.bpo.3-amd64 and XEN 4.0-amd64' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_gpt insmod ext2 set root='(hd0,gpt1)' search --no-floppy --fs-uuid --set 92c05f33-db01-4031-a09b-5c09e8ad5549 echo 'Chargement de Linux 3.2.0-0.bpo.3-amd64 ...' multiboot /xen-4.0-amd64.gz placeholder dom0_mem=2048M module /vmlinuz-3.2.0-0.bpo.3-amd64 placeholder root=UUID=df366381-0506-4b3b-8d4d-e393696a5866 ro rootdelay=40 quiet echo 'Chargement du disque mÃ©moire initial ...' module /initrd.img-3.2.0-0.bpo.3-amd64

mon entrée modifié :

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' --class debian --class gnu-linux --class gnu --class os --class xen { insmod part_gpt insmod ext2 set root='(hd0,gpt1)' search --no-floppy --fs-uuid --set 92c05f33-db01-4031-a09b-5c09e8ad5549 echo 'Chargement de Linux 2.6.32-5-xen-amd64 ...' multiboot /xen-4.0-amd64.gz placeholder dom0_mem=2048M module /vmlinuz-2.6.32-5-xen-amd64 placeholder root=/dev/sda2 ro rootdelay=40 quiet echo 'Chargement du disque mÃ©moire initial ...' module /initrd.img-2.6.32-5-xen-amd64

et je reboot, et patatra :

[code]mdadm no devices listed in conf file were found

ALERT /dev/sda2 does not exist[/code]

mmh c’est bizarre bizarre, le système a bien l’information du bon disque… Le serveur est un dedibox, de chez online.net, leur système de partitionnement en ligne ne marchait pas, je ne pouvais donc pas libérer de l’espace en redimensionnant le disque sous debian car / monté, j’ai donc boot via le kvm une iso de gparted, j’ai libérer de l’espace pour créer une /dev/sda4 puis j’ai monter un lvm,

pvcreate /dev/sda4
vgcreate vg0 /dev/sda4

#LVM /data
lvcreate -L 200G -n lv_data vg0
mkfs.ext3 /dev/vg0/lv_data
mkdir -p /data
mount /dev/vg0/lv_data /data
echo "/dev/vg0/lv_data /data ext3 defaults 0 2" >>/etc/fstab;

Si je regarde du coté d’un autre xen server ou mon noyau est en 2.6.32-5-xen-amd64 le boot se fait comme ça :

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' --class debian --class gnu-linux --class gnu --class os --class xen {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set 1a3b5d30-ac97-445c-9266-b40f27bd01ce
        echo    'Chargement de Linux 2.6.32-5-xen-amd64 ...'
        multiboot       /xen-4.0-amd64.gz placeholder
        module  /vmlinuz-2.6.32-5-xen-amd64 placeholder root=UUID=fbfc8dac-8b2e-4900-bc30-75ef3e9b5270 ro  quiet
        echo    'Chargement du disque mÃ©moire initial ...'
        module  /initrd.img-2.6.32-5-xen-amd64

Du coup j’ai fais un update initframfs

[code]root@sd-37359:/boot# update-initramfs -u -k 3.2.0-0.bpo.3-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-0.bpo.3-amd64
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.

root@sd-37359:/boot# update-initramfs -t -u -k 2.6.32-5-xen-amd64
update-initramfs: Generating /boot/initrd.img-2.6.32-5-xen-amd64
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
W: mdadm: no arrays defined in configuration file.[/code]

Ça me dépasse comment d’un kernel à l’autre dans le grub loader avec les mêmes informations il peut ne pas réussir à boot sur la bonne partition ??

J’essaye avec un :

g373 · Février 21, 2016, 2:01pm

Voila le boot avec kernel 3.2.0 qui est OK (je ne pose pas dans une balise img c’est limité à 600 px

http://img545.imageshack.us/img545/8384/sanstitredrh.png

et avec la modification du set root=’(hd0,0)’ pareil…

http://img197.imageshack.us/img197/392/sanstijtre.png

g373 · Février 21, 2016, 2:02pm

Any idea ? :-/