Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

noyau 4.0 et lvm sur raid logiciel

3 réponses
Avatar
Jean-Michel OLTRA
Bonjour,


J'ai tenté de booter sur le nouveau noyau 4.0.0-2 sur Testing, sans
succès. J'ai un volume physique sur un volume raid, comme le montre les
sorties suivantes.


espinasse:/home/jm$ pvs
PV VG Fmt Attr PSize PFree
/dev/md3 debian lvm2 a-- 223,01g 35,71g

espinasse:/home/jm$ lvs
LV VG Attr LSize
backtrack debian -wi-a----- 25,00g
i386 debian -wi-a----- 20,00g
lvhome debian -wi-ao---- 60,00g
lvlaurena debian -wi-ao---- 2,00g
lvtmp debian -wi-ao---- 300,00m
lvusr debian -wi-ao---- 30,00g
lvvar debian -wi-ao---- 50,00g

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md2 / ext3 defaults,errors=remount-ro 0 1
/dev/md0 /boot ext3 defaults 0 2
/dev/mapper/debian-lvhome /home xfs defaults 0 2
/dev/mapper/debian-lvtmp /tmp xfs defaults 0 2
/dev/mapper/debian-lvusr /usr xfs defaults 0 2
/dev/mapper/debian-lvvar /var xfs defaults 0 2
/dev/mapper/debian-lvlaurena /home/laurena xfs defaults 0 2
/dev/md1 none swap sw 0 0

Lors du boot avec le 4.0, systemd n'arrive pas à trouver les volumes logiques
lv*, sauf lvusr qui est correctement monté. Et je me retrouve alors sur
le "Ctrl-D to continue or type root password for maintenance"

L'utilisation d'instructions comme pvs, pvscan, lvs (ou les équivalents
en *display) mouline dans le vide.

Quelqu'un aurait il eu un cas similaire ? Le noyau 3.16 fonctionne très
bien, en revanche, donc il n'y a pas le feu.

Merci.

--
jm

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20150728100010.GE2705@espinasse

3 réponses

Avatar
Gilles Mocellin
Salut,

Bug référencé sur lvm2 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy1869

Solution en attendant : dans /etc/lvm/lvm.conf, mettre à 0 :
use_lvmetad = 0

Et regénérer l'initramfs (update-initramfs -u)


Le 28/07/2015 12:00, Jean-Michel OLTRA a écrit :
Bonjour,


J'ai tenté de booter sur le nouveau noyau 4.0.0-2 sur Testing, sans
succès. J'ai un volume physique sur un volume raid, comme le montre les
sorties suivantes.


espinasse:/home/jm$ pvs
PV VG Fmt Attr PSize PFree
/dev/md3 debian lvm2 a-- 223,01g 35,71g

espinasse:/home/jm$ lvs
LV VG Attr LSize
backtrack debian -wi-a----- 25,00g
i386 debian -wi-a----- 20,00g
lvhome debian -wi-ao---- 60,00g
lvlaurena debian -wi-ao---- 2,00g
lvtmp debian -wi-ao---- 300,00m
lvusr debian -wi-ao---- 30,00g
lvvar debian -wi-ao---- 50,00g

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md2 / ext3 defaults,errors=remount-ro 0 1
/dev/md0 /boot ext3 defaults 0 2
/dev/mapper/debian-lvhome /home xfs defaults 0 2
/dev/mapper/debian-lvtmp /tmp xfs defaults 0 2
/dev/mapper/debian-lvusr /usr xfs defaults 0 2
/dev/mapper/debian-lvvar /var xfs defaults 0 2
/dev/mapper/debian-lvlaurena /home/laurena xfs defaults 0 2
/dev/md1 none swap sw 0 0

Lors du boot avec le 4.0, systemd n'arrive pas à trouver les volumes logiques
lv*, sauf lvusr qui est correctement monté. Et je me retrouve alors sur
le "Ctrl-D to continue or type root password for maintenance"

L'utilisation d'instructions comme pvs, pvscan, lvs (ou les équivalents
en *display) mouline dans le vide.

Quelqu'un aurait il eu un cas similaire ? Le noyau 3.16 fonctionne très
bien, en revanche, donc il n'y a pas le feu.

Merci.





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Jean-Michel OLTRA
Bonjour,


Le mercredi 29 juillet 2015, Gilles Mocellin a écrit...


Bug référencé sur lvm2 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy1869

Solution en attendant : dans /etc/lvm/lvm.conf, mettre à 0 :
use_lvmetad = 0

Et regénérer l'initramfs (update-initramfs -u)



use_lvmetad est déjà à 0.

J'ai quand même testé `pvscan --cache` puis `update-initramfs -u`, mais
la punition est identique…

Merci de t'être penché sur mon problème. Il me faudrait peut-être mieux
éplucher le rapport de bug pour voir si j'ai autre chose à en tirer.

--
jm

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Jean-Michel OLTRA
Bonjour,


Le mercredi 29 juillet 2015, Jean-Michel OLTRA a écrit...



> Bug référencé sur lvm2 :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bugy1869



Corrigé depuis la dernière mise à jour de lvm2.

Reste une erreur (failed au démarrage) sur systemd-udev-settle.service,
mais ça ne semble pas impacter le système.

--
jm