[boot] Volume LVM pour /home parfois non activé au démarrage (résolu)
[boot] Volume LVM pour /home parfois non activé au démarrage (résolu)
Bonjour à tous,
J'ai récemment installé Archlinux sur mon laptop et tout fonctionne bien, à un détail près : parfois, le volume LVM /home n'est pas activé lors du boot.
Plus précisément, systemd m'indique « running job for /dev/disk/by-uuid », pendant 1m30, puis, je me retrouve sur un shell de maintenance.
Lorsque je jette un œil avec vgs, je constate que le volume group contenant mon volume /home n'est pas actif. Il me suffit alors de l'activé avec la commande vgchange -ay <mon_volume> pour que tout rentre dans l'ordre.
À noter que simplement rebooter m'évite le timeout d'1m 30 et résout également le problème.
Concernant ma config : je dispose de deux disques : 1 SSD et un HDD. Les deux sont partitionnés avec GPT. J'ai construit deux volumes LUKS sur chaque disque avec du LVM par-dessus. Le volume LVM du SSD sert pour le système et le volume LVM sur le HDD contient mon /home.
J'ai le sentiment que c'est un problème lié à l'ordonnancement des services par systemd (dans le sens où il essayerait de toucher au /home trop tôt), mais je ne sais pas trop par où commencer mes recherches.
Est-ce qu'une bonne âme aurait une idée pour résoudre ce petit souci ?
J'ai récemment installé Archlinux sur mon laptop et tout fonctionne bien, à un détail près : parfois, le volume LVM /home n'est pas activé lors du boot.
Plus précisément, systemd m'indique « running job for /dev/disk/by-uuid », pendant 1m30, puis, je me retrouve sur un shell de maintenance.
Lorsque je jette un œil avec vgs, je constate que le volume group contenant mon volume /home n'est pas actif. Il me suffit alors de l'activé avec la commande vgchange -ay <mon_volume> pour que tout rentre dans l'ordre.
À noter que simplement rebooter m'évite le timeout d'1m 30 et résout également le problème.
Concernant ma config : je dispose de deux disques : 1 SSD et un HDD. Les deux sont partitionnés avec GPT. J'ai construit deux volumes LUKS sur chaque disque avec du LVM par-dessus. Le volume LVM du SSD sert pour le système et le volume LVM sur le HDD contient mon /home.
J'ai le sentiment que c'est un problème lié à l'ordonnancement des services par systemd (dans le sens où il essayerait de toucher au /home trop tôt), mais je ne sais pas trop par où commencer mes recherches.
Est-ce qu'une bonne âme aurait une idée pour résoudre ce petit souci ?
Dernière modification par Taurre le mar. 22 juin 2021, 20:03, modifié 4 fois.
- benjarobin
- Maître du Kyudo
- Messages : 17288
- Inscription : sam. 30 mai 2009, 15:48
- Localisation : Lyon
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Bonjour,
Peux tu donner le contenu de ton fstab ?
Ainsi que la sortie (en root) de :
Dans la cas d'un LVM, il est déconseillé d'utiliser les UUID dans le fstab, comme dans la ligne de commande du kernel, mais plutôt le chemin "/dev/mapper/...".
En effet sinon systemd ne peut pas générer correctement les dépendances car il ne peut pas "deviner" que le système de fichier via son UUID que tu essayes de monter est dans un LVM.
Peux tu donner le contenu de ton fstab ?
Ainsi que la sortie (en root) de :
Code : Tout sélectionner
blkid
df -h
cat /proc/cmdline
vgs
En effet sinon systemd ne peut pas générer correctement les dépendances car il ne peut pas "deviner" que le système de fichier via son UUID que tu essayes de monter est dans un LVM.
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Merci de ta réponse.
Voici la sortie des commandes demandées.
Voici la sortie des commandes demandées.
Code : Tout sélectionner
# cat /etc/fstab
# /dev/mapper/vgroot-root
UUID=d2cc0a80-e5fd-4e4c-8046-d860f95a76fa / ext4 rw,relatime 0 1
# /dev/sdb1
UUID=DA3D-CE95 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/mapper/vghome-home
UUID=d3260dbe-7012-49ec-9682-4dd6e497a27c /home ext4 rw,relatime 0 2
# /dev/mapper/vgroot-tmp
UUID=5501ffb7-3329-49e9-a4a7-a7613eedaf57 /tmp ext2 rw,relatime 0 2
# /dev/mapper/vgroot-var
UUID=f00180a6-9c96-41e9-ad04-c15b03d58290 /var ext4 rw,relatime 0 2
# /dev/mapper/vgroot-swap
UUID=4188348a-8924-45a3-abc9-b7f2e2283b33 none swap defaults 0 0
# blkid
/dev/mapper/vgroot-root: UUID="d2cc0a80-e5fd-4e4c-8046-d860f95a76fa" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdb2: UUID="c70cc098-d5cd-4fd6-b3ea-09dcff335b0b" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="1ab704c3-fb58-429c-9aeb-3d14551fbb1c"
/dev/sdb1: UUID="DA3D-CE95" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="6d87ff48-3087-42c6-8b38-d6337216e5ee"
/dev/mapper/vghome-home: UUID="d3260dbe-7012-49ec-9682-4dd6e497a27c" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vgroot-var: UUID="f00180a6-9c96-41e9-ad04-c15b03d58290" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vgroot-swap: UUID="4188348a-8924-45a3-abc9-b7f2e2283b33" TYPE="swap"
/dev/mapper/cryptroot: UUID="8zjdwP-EgPc-46yf-oLGY-9PCT-9Emx-YQSwVK" TYPE="LVM2_member"
/dev/sda1: UUID="473f021f-5c1b-4f9a-8413-2f161942fa7d" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="a1015ebe-1b31-4a50-8514-2eb9754fd920"
/dev/mapper/crypthome: UUID="YPrJXn-EbSO-K5xJ-m3iN-iX0H-NCnZ-aJFr6e" TYPE="LVM2_member"
/dev/mapper/vgroot-tmp: UUID="5501ffb7-3329-49e9-a4a7-a7613eedaf57" BLOCK_SIZE="4096" TYPE="ext2"
[root@euzebe ~]# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
devtmpfs 3,8G 0 3,8G 0% /dev
tmpfs 3,8G 928K 3,8G 1% /dev/shm
tmpfs 1,6G 9,2M 1,6G 1% /run
/dev/mapper/vgroot-root 63G 4,4G 55G 8% /
/dev/mapper/vgroot-var 7,8G 1,4G 6,1G 19% /var
/dev/mapper/vgroot-tmp 7,9G 313M 7,2G 5% /tmp
/dev/sdb1 1022M 77M 945M 8% /boot
/dev/mapper/vghome-home 458G 134G 301G 31% /home
tmpfs 778M 16K 778M 1% /run/user/1000
# cat /proc/cmdline
root=/dev/vgroot/root rw initrd=\intel-ucode.img initrd=\initramfs-linux.img
# vgs
VG #PV #LV #SN Attr VSize VFree
vghome 1 1 0 wz--n- 465,74g 0
vgroot 1 4 0 wz--n- 222,55g 138,05g
Ah ! J'ignorais ceci, merci, le problème est peut-être bien là.En effet sinon systemd ne peut pas générer correctement les dépendances car il ne peut pas "deviner" que le système de fichier via son UUID que tu essayes de monter est dans un LVM.
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Yep, après plusieurs reboot cela semble tenir si je rempalce l'UUID par /dev/mapper/vg-home-home.
Merci beaucoup.
Merci beaucoup.
- benjarobin
- Maître du Kyudo
- Messages : 17288
- Inscription : sam. 30 mai 2009, 15:48
- Localisation : Lyon
Re: [boot] Volume LVM pour /home parfois non activé au démarrage (résolu)
Je te conseil de changer tous tes points de montage LVM (et pas uniquement celui du home).
En gros il faut éviter d'utiliser directement le nom du device, car le nom peut être aléatoire. Les UUID dans ce cas là sont très bien. Mais s'il y a surcouche quelconque (RAID, LVM, ...) il faut toujours utiliser le chemin du "device virtuel" (/dev/mapper/...). Cela ne pose aucun problème car /dev/mapper/vghome-home sera toujours unique dans ton système et se nommera toujours ainsi
En gros il faut éviter d'utiliser directement le nom du device, car le nom peut être aléatoire. Les UUID dans ce cas là sont très bien. Mais s'il y a surcouche quelconque (RAID, LVM, ...) il faut toujours utiliser le chemin du "device virtuel" (/dev/mapper/...). Cela ne pose aucun problème car /dev/mapper/vghome-home sera toujours unique dans ton système et se nommera toujours ainsi
Zsh | KDE | PC fixe : core i7, carte nvidia
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Titre d'un sujet : [Thème] Sujet (état) / Règles du forum
Re: [boot] Volume LVM pour /home parfois non activé au démarrage (résolu)
Ok, je note et je change ça.
Merci beaucoup de ton aide.
Merci beaucoup de ton aide.
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
J'ai visiblement parlé un peu vite, j'ai finalement rencontré le problème même en utilisant les chemins en /dev/mapper/...
Si cela peut être utile, je remets le résultat de la liste de commande demandée ci-dessous.
Si cela peut être utile, je remets le résultat de la liste de commande demandée ci-dessous.
Code : Tout sélectionner
# cat /etc/fstab
/dev/mapper/vgroot-root / ext4 rw,relatime 0 1
# /dev/sdb1
UUID=DA3D-CE95 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
/dev/mapper/vghome-home /home ext4 rw,relatime 0 2
/dev/mapper/vgroot-tmp /tmp ext2 rw,relatime 0 2
/dev/mapper/vgroot-var /var ext4 rw,relatime 0 2
/dev/mapper/vgroot-swap none swap defaults 0 0
# blkid
/dev/mapper/vgroot-root: UUID="d2cc0a80-e5fd-4e4c-8046-d860f95a76fa" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdb2: UUID="c70cc098-d5cd-4fd6-b3ea-09dcff335b0b" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="1ab704c3-fb58-429c-9aeb-3d14551fbb1c"
/dev/sdb1: UUID="DA3D-CE95" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="6d87ff48-3087-42c6-8b38-d6337216e5ee"
/dev/mapper/vghome-home: UUID="d3260dbe-7012-49ec-9682-4dd6e497a27c" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vgroot-var: UUID="f00180a6-9c96-41e9-ad04-c15b03d58290" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/vgroot-swap: UUID="4188348a-8924-45a3-abc9-b7f2e2283b33" TYPE="swap"
/dev/mapper/cryptroot: UUID="8zjdwP-EgPc-46yf-oLGY-9PCT-9Emx-YQSwVK" TYPE="LVM2_member"
/dev/sda1: UUID="473f021f-5c1b-4f9a-8413-2f161942fa7d" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="a1015ebe-1b31-4a50-8514-2eb9754fd920"
/dev/mapper/crypthome: UUID="YPrJXn-EbSO-K5xJ-m3iN-iX0H-NCnZ-aJFr6e" TYPE="LVM2_member"
/dev/mapper/vgroot-tmp: UUID="5501ffb7-3329-49e9-a4a7-a7613eedaf57" BLOCK_SIZE="4096" TYPE="ext2"
# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
devtmpfs 3,8G 0 3,8G 0% /dev
tmpfs 3,8G 0 3,8G 0% /dev/shm
tmpfs 1,6G 9,2M 1,6G 1% /run
/dev/mapper/vgroot-root 63G 4,4G 55G 8% /
/dev/mapper/vgroot-var 7,8G 1,4G 6,1G 19% /var
/dev/mapper/vgroot-tmp 7,9G 313M 7,2G 5% /tmp
/dev/sdb1 1022M 77M 945M 8% /boot
/dev/mapper/vghome-home 458G 135G 300G 31% /home
tmpfs 778M 16K 778M 1% /run/user/1000
# cat /proc/cmdline
root=/dev/vgroot/root rw initrd=\intel-ucode.img initrd=\initramfs-linux.img
# vgs
VG #PV #LV #SN Attr VSize VFree
vghome 1 1 0 wz--n- 465,74g 0
vgroot 1 4 0 wz--n- 222,55g 138,05g
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Bonjour,
D'après le retour de cat /proc/cmdline, le système n'est pas configuré selon les recommandations du wiki de "LMV on LUKS", de là à penser qu'il y a une relation de cause à effet...
https://wiki.archlinux.org/title/Dm-cry ... t_loader_2
Vérifie aussi la configuration de mkinitcpio
https://wiki.archlinux.org/title/Dm-cry ... initcpio_2
D'après le retour de cat /proc/cmdline, le système n'est pas configuré selon les recommandations du wiki de "LMV on LUKS", de là à penser qu'il y a une relation de cause à effet...
https://wiki.archlinux.org/title/Dm-cry ... t_loader_2
Vérifie aussi la configuration de mkinitcpio
https://wiki.archlinux.org/title/Dm-cry ... initcpio_2
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Merci de ta réponse.
En fait, c'est parce que j'utilise un fichier /etc/crypttab.initramfs, dans un tel cas il est précisé de ne pas utiliser la syntaxe rd.xxx. C'est précisé dans l'encart rouge de cette section : https://wiki.archlinux.org/title/Dm-cry ... crypt_hook.
Maintenant j'ai peut-être mal interprété ce qu'il y est dit.
En fait, c'est parce que j'utilise un fichier /etc/crypttab.initramfs, dans un tel cas il est précisé de ne pas utiliser la syntaxe rd.xxx. C'est précisé dans l'encart rouge de cette section : https://wiki.archlinux.org/title/Dm-cry ... crypt_hook.
Maintenant j'ai peut-être mal interprété ce qu'il y est dit.
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Je comprends la même chose que toi. Quels sont les paramètres que tu utilises pour HOOKS= ? Il n'y a rien d'intéressant dans les logs concernant lvm ?
Code : Tout sélectionner
journalctl -b
Re: [boot] Volume LVM pour /home parfois non activé au démarrage
Pour les paramètres, j'utilise ceux-ci, recommandés pour sd-encrypt.
Pour journalctl, a priori rien de pertinent côté lvm, juste des logs décrivant un fonctionnement normal (activation des volumes, etc.).
Cela étant, je pense avoir trouvé la source du problème : moi. ^^"
En fait, j'ai précisé les deux volumes LUKS dans /etc/crypttab.initramfs, ce qui n'est pas un souci, cependant, cela produit deux comportements assez étranges :
1. L'ordre dans lequel le mot de passe est demandé semble aléatoire, une fois il me demande le mot de passe pour le volume contenant la racine en premier, une autre fois il me demandera celui contenant /home en premier.
2. En cas d'erreur de saisie pour le premier volume, celui du second va être demandé (jusque-là, c'est logique). Néanmoins, une fois le mot de passe entré pour le second volume, celui du premier va être à nouveau demandé et ce, même si le mot de passe des deux volumes est identique, ce qui est mon cas (et du coup, là, c'est moins logique).
Tout cela pour dire qu'à mon avis, j'ai dû me foirer dans mon mot de passe pour le volume /home la dernière fois et du coup le volume LVM n'a forcément pas pu être monté. Même erreur, mais cause différente. J'ai juste été un peu confus à cause de ce comportement, je pense. Histoire de l'évité, j'ai crée un fichier /etc/crypttab et placé l'entrée pour /home dedans. Comme cela, seul le mot de passe pour la racine est demandé au tout début du boot.
Désolé du dérangement et merci pour votre aide.
Je passe le sujet en résolu.
Code : Tout sélectionner
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt lvm2 filesystems fsck)
Cela étant, je pense avoir trouvé la source du problème : moi. ^^"
En fait, j'ai précisé les deux volumes LUKS dans /etc/crypttab.initramfs, ce qui n'est pas un souci, cependant, cela produit deux comportements assez étranges :
1. L'ordre dans lequel le mot de passe est demandé semble aléatoire, une fois il me demande le mot de passe pour le volume contenant la racine en premier, une autre fois il me demandera celui contenant /home en premier.
2. En cas d'erreur de saisie pour le premier volume, celui du second va être demandé (jusque-là, c'est logique). Néanmoins, une fois le mot de passe entré pour le second volume, celui du premier va être à nouveau demandé et ce, même si le mot de passe des deux volumes est identique, ce qui est mon cas (et du coup, là, c'est moins logique).
Tout cela pour dire qu'à mon avis, j'ai dû me foirer dans mon mot de passe pour le volume /home la dernière fois et du coup le volume LVM n'a forcément pas pu être monté. Même erreur, mais cause différente. J'ai juste été un peu confus à cause de ce comportement, je pense. Histoire de l'évité, j'ai crée un fichier /etc/crypttab et placé l'entrée pour /home dedans. Comme cela, seul le mot de passe pour la racine est demandé au tout début du boot.
Désolé du dérangement et merci pour votre aide.
Je passe le sujet en résolu.