Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 01/04/2021, à 15:37

Arbiel

[Contournement] Attente exagérée au démarrage

Bonjour à tous

Le titre initial était
Diminuer la fréquence de la vérification des disques au démarrage
Le message affiché à l'écran ne correspondait pas vraiment au problème qui concerne une certaine incohérence entre initrd.img et le fichier /etc/crypttab. Voir ici pour les explications

Après l'installation de la 20.04 sur un nouvel ordinateur, j'ai constaté que le système vérifie mes disques à chaque démarrage. Je veux diminuer la fréquence de ces vérifications.

En suivant les indications de la page, j'ai fixé à 100 le nombre maximum de démarrages sans vérification et à 30 jours l'intervalle maximum entre deux vérifications successives.

Mes disques sont des volumes logiques. J'ai extrait les informations relatives au système de fichiers de l'un d'entre eux, puis pour chacun les dates de dernière vérification, dernière écriture et dernier montage. Ci-dessous le retour des commandes exécutées :
(s et g sont des alias pour sudo et grep)

arbiel@arbiel-NK3S-8-S4:~$ sudo tune2fs -l /dev/mapper/philippe-rhizot
tune2fs 1.45.5 (07-Jan-2020)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5ab1950c-cd24-42d3-a4a6-256985877370
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              983040
Block count:              3928064
Reserved block count:     196403
Free blocks:              3158745
Free inodes:              967705
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Mar 28 16:26:57 2021
Last mount time:          Thu Apr  1 16:08:25 2021
Last write time:          Thu Apr  1 16:08:25 2021
Mount count:              24
Maximum mount count:      100
Last checked:             Sun Mar 28 16:26:57 2021
Check interval:           2592000 (1 month)
Next check after:         Tue Apr 27 16:26:57 2021
Lifetime writes:          8 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      163b8437-33f8-4c95-b971-7d9a643d96db
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x53184122
arbiel@arbiel-NK3S-8-S4:~$ for lv in $(s lvdisplay philippe | g Path | g -v _l | grep -o -E "/dev.*$"); do echo ; echo "${lv}" ; sudo tune2fs -l ${lv} | grep -Ei "Last" ; done ;

/dev/philippe/secours
Last mounted on:          /home/arbiel/.bash_aliases
Last mount time:          Thu Apr  1 16:08:29 2021
Last write time:          Thu Apr  1 16:08:29 2021
Last checked:             Tue Mar 23 23:40:32 2021

/dev/philippe/xavier
Last mounted on:          /boot
Last mount time:          Thu Apr  1 16:08:29 2021
Last write time:          Thu Apr  1 16:08:29 2021
Last checked:             Sun Mar 28 16:26:56 2021

/dev/philippe/usr
Last mounted on:          /usr
Last mount time:          Thu Apr  1 16:08:25 2021
Last write time:          Thu Apr  1 16:08:25 2021
Last checked:             Sun Mar 28 16:26:58 2021

/dev/philippe/gumnon
Last mounted on:          /home/arbiel/Documents/gumnon
Last mount time:          Thu Apr  1 14:36:26 2021
Last write time:          Thu Apr  1 15:30:04 2021
Last checked:             Tue Mar 30 11:21:49 2021

/dev/philippe/psilos
Last mounted on:          /home/arbiel/.local/share/applications
Last mount time:          Thu Apr  1 14:36:26 2021
Last write time:          Thu Apr  1 15:30:04 2021
Last checked:             Tue Mar 30 22:07:00 2021

/dev/philippe/eidonta
Last mounted on:          /home/arbiel/Bureau/Vidéos
Last mount time:          Thu Apr  1 16:09:55 2021
Last write time:          Thu Apr  1 16:09:55 2021
Last checked:             Tue Mar 30 22:07:36 2021

/dev/philippe/phortos
Last mounted on:          /home/arbiel/Téléchargements
Last mount time:          Thu Apr  1 16:09:55 2021
Last write time:          Thu Apr  1 16:09:55 2021
Last checked:             Tue Mar 30 22:08:16 2021

/dev/philippe/biblioi
Last mounted on:          /home/arbiel/Bureau/Bibliothèque
Last mount time:          Thu Apr  1 16:09:55 2021
Last write time:          Thu Apr  1 16:09:55 2021
Last checked:             Tue Mar 30 22:09:27 2021

/dev/philippe/melopoi
Last mounted on:          /home/arbiel/Bureau/Musique
Last mount time:          Thu Apr  1 16:09:55 2021
Last write time:          Thu Apr  1 16:09:55 2021
Last checked:             Tue Mar 30 22:08:58 2021
arbiel@arbiel-NK3S-8-S4:~$ 

Bien qu'apparemment la date de dernier montage soit antérieure à celle de dermière utilisation, le système continue à vérifier les volumes logiques à chaque démarrage.

Merci de bien vouloir m'indiquer sur quel autre paramètre je dois intervenir.

Arbiel

Dernière modification par Arbiel (Le 14/04/2021, à 09:32)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#2 Le 01/04/2021, à 19:28

iznobe

Re : [Contournement] Attente exagérée au démarrage

Bonjour , generalement les reglages a partir de tune fs ne sont pris en charge qu ' apres modification du fstab .
Donc il faudrait nous fournir ton fichier /etc/fstab .

De memoire il me semble que c ' est le dernier des 6 parametres a passer soit a 1 ou a 2 .
si il est par defaut a 2 tente avec 1 ca devrait le faire ou vice versa big_smile

EDIT : je viens de verifier mon fstab , il faut mettre 2 pour activer les verifs tunefs .et 1 pour verif auto a achaque demarrage , selon moi .
une recherche sur le net te confirmera surement si c ' est le cas ou pas .

Dernière modification par iznobe (Le 01/04/2021, à 19:30)


retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

Hors ligne

#3 Le 02/04/2021, à 18:47

Arbiel

Re : [Contournement] Attente exagérée au démarrage

Bonsoir

Mon fichier fstab est identique à ce qu'il a été pendant de nombreuses années, et pendant toutes ces années, depuis la 12.04 jusqu'à la 18.04 je n'ai jamais rencontré ce problème.

Je n'ai pas vu dans la page de manuel de fstab l'apparition d'une nouvelle option de montage qui impliquerait une analyse systématique des systèmes de fichiers au démarrage. Je n'ai pas l'intention de supprimer totalement cette vérification en annulant le sixième paramètre des lignes de fstab, celui qui donne la priorité des systèmes de fichier par rapport à ces analyses, et qui indique, lorsqu'il est nul, ou absent, qu'aucune analyse ne doit être effectuée.

man fstab a écrit :

       The sixth field (fs_passno).
              This field is used by fsck(8) to determine the  order  in  which
              filesystem  checks  are  done at boot time.  The root filesystem
              should be specified with a fs_passno of  1.   Other  filesystems
              should  have  a fs_passno of 2.  Filesystems within a drive will
              be checked sequentially, but  filesystems  on  different  drives
              will  be  checked at the same time to utilize parallelism avail‐
              able in the hardware.  Defaults to  zero  (don't  fsck)  if  not
              present.

Ce que je cherche à savoir, c'est quel paramètre modifier, et comment le modifier, pour que ces analyses soient effectuées conformément aux valeurs que j'ai enregistrées avec tune2fs.

Il est cependant possible que le message qui m'indique la vérification des systèmes de fichiers soit erroné et que mon PC fasse autre chose pendant ce temps. En effet :

1) Ctrl_C, contrairement à ce qu'indique le message, n'interrompt pas le processus
2) il n'apparaît aucun message lorsque je démarre avec mon deuxième système, (mon système de secours où tout est intégré dans la partition racine), et dont le démarrage est également un peu long.
3) les dates de dernière vérification des systèmes de fichiers sont restées identiques à celles que j'ai affichées en ouvrant cette discussion, alors que j'ai arrêté et redémarré ma machine à plusieurs reprises depuis.

Je dois également indiquer que, pour ce qui concerne mon système opérationnel, la partition racine et la partition personnelle sont chiffrées, chacune avec leur propre clé de chiffrement, clés enregistrées sur mes clés USB (comme je fais depuis plusieurs années)

Arbiel

Dernière modification par Arbiel (Le 02/04/2021, à 19:03)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#4 Le 02/04/2021, à 18:57

MicP

Re : [Contournement] Attente exagérée au démarrage

Bonjour

Peut-être quelques pistes à creuser dans le wiki d'archlinux : https://wiki.archlinux.org/index.php/fsck
et aussi dans ce fil de discussion du forum manjaro : https://forum.manjaro.org/t/etc-fstab-and-fsck/30092

Hors ligne

#5 Le 02/04/2021, à 19:27

Arbiel

Re : [Contournement] Attente exagérée au démarrage

Bonsoir MicP

Je te remercie. Je viens de jeter un œil, et ce bref aperçu m'incite à y regarder de plus près.

D'autant plus que j'ai remarqué une modification importante de systemd par rapport aux partitions chiffrées. J'avais dû sauter la 16.04 avec laquelle je ne parvenais pas à faire démarrer mon PC. J'ai retrouvé la même difficulté avec le 18.04 et j'ai creusé le problème du fait de la proximité de la fin de vie de la 14.04. Pour le contourner, j'ai dû vider /etc/crypttab, ce qui a débloqué le démarrage, et monter le «vrai» crypttab par fstab pour garantir la validité de l'initrd.img en cas d'exécution automatique de update-initramfs,

Je n'ai pas eu à mettre en œuvre ce subterfuge avec la 20.04.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#6 Le 02/04/2021, à 20:54

Coeur Noir

Re : [Contournement] Attente exagérée au démarrage

Pour ma culture perso : comment fsck vérifie des partitions chiffrées ? Il ne traite que la partie déchiffrée ( ce qui rallongerait la procédure ) ou la partie chiffrée lui est quand même accessible ( disons qu'il vérifie des données brutes et qu'il s'en fout qu'elles soient chiffrées ou pas ) ?

Sinon que raconte

sudo tune2fs -l /dev/sdXz | grep -Ei "Mount count|Maximum mount|Filesystem created|check"

en remplaçant bien sûr sdXz par la ou les partitions de ton choix ?


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#7 Le 02/04/2021, à 22:32

iznobe

Re : [Contournement] Attente exagérée au démarrage

Bonsoir , une lecture peut etre interressante a plus d' un titre sur mon message precedent :
https://doc.ubuntu-fr.org/verification_de_fichiers
tiré de la page precedemment linké :

Il y a une condition impérative pour que fsck vérifie une partition : il faut que le dernier chiffre - le sixième champ - de la ligne décrivant chaque partition dans /etc/fstab ne soit pas nul. En général la partition racine a une priorité 1 et les autres partitions Linux une priorité 2. Vérifiez-le.

Mais bon , je ne vous apprend rien , vous avez l' air de savoir bien plus de chose que moi .

Dernière modification par iznobe (Le 02/04/2021, à 22:33)


retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

Hors ligne

#8 Le 02/04/2021, à 23:20

Arbiel

Re : [Contournement] Attente exagérée au démarrage

Bonsoir Cœur Noir

Non, fsck ne sait pas analyser une partition chiffrée. Comme tu l'écris, fsck ne sait analyser que les partitions claires. LUKS n'est pas un système de fichiers GNU/Linux. La page du manuel le laisse clairement comprendre:

man fsck a écrit :

DESCRIPTION
       fsck is used to check and optionally repair one or more Linux  filesys‐
       tems.   filesys  can  be  a device name (e.g.  /dev/hdc1, /dev/sdb2), a
       mount point (e.g.  /, /usr, /home), or  an  filesystem  label  or  UUID
       specifier   (e.g.    UUID=8868abf6-88c5-4a83-98b8-bfc24057f7bd  or  LA‐
       BEL=root).

       In  actuality,  fsck is simply a front-end for the various filesystem checkers (fsck.fstype) available under Linux.  The filesystem-spe‐
       cific checker is searched for in the PATH environment variable. If the PATH is undefined then fallback to "/sbin".


SEE ALSO
       fstab(5), mkfs(8), fsck.ext2(8) or fsck.ext3(8) or e2fsck(8), cramfsck(8), fsck.jfs(8), fsck.nfs(8), fsck.minix(8), fsck.msdos(8),
       fsck.vfat(8), fsck.xfs(8), reiserfsck(8)

Les données brutes enregistrées dans une partition chiffrées n'ont aucun sens pour qui ne dispose pas de la clé de chiffrement.

Dans le second bloc de code du #1 de cette discussion, j'ai exécuté la commande tune2fs que tu me conseille d'exécuter, et j'ai choisi les lignes relatives à de «dernières» opérations, à savoir montage, écriture et vérification pour constater que la dernière vérification est antérieure au dernier montage, ce qui est en contradiction avec le message qui m'indique, à chaque démarrage, que la vérification des systèmes de fichiers est en cours.

Les informations qui y sont présentées concernent les partitions claires, c'est-à-dire les partitions non chiffrées et les partitions préalablement déchiffrées. Comme elles sont toutes des volumes logiques d'un LVM, j'ai collecté leur nom par un lvdisplay, et j'ai éliminées celles qui sont suffixées par _l, le suffixe que j'utilise pour distinguer chaque partition chiffrée de la partition claire qui lui correspond.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#9 Le 02/04/2021, à 23:53

Coeur Noir

Re : [Contournement] Attente exagérée au démarrage

j'ai exécuté la commande tune2fs que tu me conseille d'exécuter → y'a le check en plus, pour voir quand est prévue une prochaine vérification ( et si ça correspond peu ou prou à ton réglage ).

Les données brutes enregistrées dans une partition chiffrées n'ont aucun sens pour qui ne dispose pas de la clé de chiffrement. Oui, d'un point de vue humain. Je me disais juste ça reste des données sur un disque, écrites dans des blocs / secteurs / etc, et puisque c'est ça que vérifie un fsck - et pas la fonction des données elles-mêmes - peut être que c'est la partition chiffrée qui aurait besoin d'un coup de frais ?

Est-il possible qu'une vérification se lance parce qu'un support le demanderait lui-même, en cas d'erreur, d'usure ? Ou qu'une fonctionnalité / un paramètre liés à LVM puisse déclencher cela ? Ou encore une option dans GRUB ( qui demanderait un fsck au démarrage, c'est faisable ça ) ?

Je réfléchis tout haut hein, désolé si ça paraît bêbête smile


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#10 Le 03/04/2021, à 01:01

MicP

Re : [Contournement] Attente exagérée au démarrage

… ça reste des données sur un disque, écrites dans des blocs / secteurs / etc,  …

Oui, mais cette suite de blocs,/secteurs/ etc. n'est pas pour autant organisée comme elle le serait dans un système de fichiers,
donc la commande fsck (FileSystem ChecK) ne pourra rien faire avec ce contenu,
ce contenu ne deviendra un système de fichier (dont la cohérence pourra alors être vérifiée par la commande fsck) qu'après que ces données auront été déchiffrées.

Dernière modification par MicP (Le 03/04/2021, à 07:34)

Hors ligne

#11 Le 03/04/2021, à 01:39

Coeur Noir

Re : [Contournement] Attente exagérée au démarrage

[ hors sujet un peu, ma curiosité ] Ok, ok… c'est vrai qu'on parle de partition ou de volume chiffrés. Dans ce cas, l'ensemble est vu comme un seul tas à chiffrer, en gros, c'est ça ? Mais alors on fait comment pour vérifier qu'il n'y a pas d'incohérence dans la partie chiffrée, il y a des outils pour ça ? Sont intégrés au mécanisme de chiffrement lui-même ? Ce mécanisme, il prévient quand un disque est faiblard, usé, avec des secteurs non alloués ? Physiquement, électriquement ça reste des 0 et des 1 à faire tenir en bon ordre sur un support, ça reste des lectures et des écritures…


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#12 Le 03/04/2021, à 07:18

iznobe

Re : [Contournement] Attente exagérée au démarrage

Bonjour ,

je n' avais pas vu dans votre premier post que la partition a verifier etait chiffrée ...
j ' ai trouvé un post ( en anglais ) qui explique comment utiliser fsck sur un volume chiffré , il date un peu , mais je suppose que le cheminement reste le meme maintenant : https://askubuntu.com/questions/1124500 … -with-fsck

ce post ci a l' air d' expliquer comment proceder pour des verifs automatiques ce qui a l' air de correspondre a votre recherche , mais ne precise pas comment modifier l' existant : https://unix.stackexchange.com/question … lvm-volume

celui ci bien que pas terriblement expliqué , parait bien plus interressant : https://forums.linuxmint.com/viewtopic.php?t=279249

d ' apres ce que j ' ai compris dans la majeure partie des post concernant fsck et LVM , c ' est que la difficulté reside dans le fait d' indiquer le bon chemin de la partition que doit analyser tune2fs qui se compose en fait de plusieurs dont une seule permet d' etre correctement analysee .

Dernière modification par iznobe (Le 03/04/2021, à 07:32)


retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

Hors ligne

#13 Le 03/04/2021, à 11:34

Arbiel

Re : [Contournement] Attente exagérée au démarrage

Bonjour

@MicP

Effectivement, dans le second bloc de code publié en #1, je n'ai pas inclus la date prévue pour la prochaine vérification. Elle est fixée, pour tous mes partitions-volumes logiques, au 29 avril prochain, ce qui n'a rien d'étonnant puisque j'avais demandé à tune2fs un intervalle de 30 jours pour toutes mes partitions.

arbiel@arbiel-NK3S-8-S4:~$ for lv in $(s lvdisplay philippe | g Path | g -v _l | grep -o -E "/dev.*$"); do echo ; echo "${lv}" ; sudo tune2fs -l ${lv} | grep -Ei "(Last|Next check)" ; done ;

/dev/philippe/secours
Last mounted on:          /home/secours
Last mount time:          Sat Apr  3 11:56:19 2021
Last write time:          Sat Apr  3 11:56:19 2021
Last checked:             Tue Mar 23 23:40:32 2021
Next check after:         Fri Apr 23 00:40:32 2021

/dev/philippe/xavier
Last mounted on:          /boot
Last mount time:          Sat Apr  3 11:56:19 2021
Last write time:          Sat Apr  3 11:56:19 2021
Last checked:             Sun Mar 28 16:26:56 2021
Next check after:         Tue Apr 27 16:26:56 2021

/dev/philippe/usr
Last mounted on:          /usr
Last mount time:          Sat Apr  3 11:56:15 2021
Last write time:          Sat Apr  3 11:56:14 2021
Last checked:             Sun Mar 28 16:26:58 2021
Next check after:         Tue Apr 27 16:26:58 2021

/dev/philippe/gumnon
Last mounted on:          /home/arbiel/Documents/gumnon
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 11:21:49 2021
Next check after:         Thu Apr 29 11:21:49 2021

/dev/philippe/psilos
Last mounted on:          /home/arbiel/Documents/psilos
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 22:07:00 2021
Next check after:         Thu Apr 29 22:07:00 2021

/dev/philippe/eidonta
Last mounted on:          /home/arbiel/Bureau/Vidéos
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 22:07:36 2021
Next check after:         Thu Apr 29 22:07:36 2021

/dev/philippe/phortos
Last mounted on:          /home/arbiel/Téléchargements
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 22:08:16 2021
Next check after:         Thu Apr 29 22:08:16 2021

/dev/philippe/biblioi
Last mounted on:          /home/arbiel/Bureau/Biblioi
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 22:09:27 2021
Next check after:         Thu Apr 29 22:09:27 2021

/dev/philippe/melopoi
Last mounted on:          /home/arbiel/Bureau/Musique
Last mount time:          Sat Apr  3 11:57:45 2021
Last write time:          Sat Apr  3 11:57:45 2021
Last checked:             Tue Mar 30 22:08:58 2021
Next check after:         Thu Apr 29 22:08:58 2021
arbiel@arbiel-NK3S-8-S4:~$ 

Tout ceci m'amène à penser que la vérification effectuée au démarrage n'est pas exécutée pas fsck, ou du moins, pas dans le contexte qui précède immédiatement le passage du contrôle à l'utilisateur. Sinon les informations données par tune2fs seraient conformes à ce que j'observe.

Je vais me concentrer sur les références que MicP m'a données, dans lesquels la lecture très rapide que j'en ai faite m'a néanmoins permis de voir que systemd exécute lui-même des contrôles, que je peux a priori régler à ma guise.

Je suis par contre surpris que ce problème n'ait pas été soulevé avant moi sur le forum, sauf à ce que je sois le seul individu à chiffrer mes volumes logiques un à un, ou le seul à désirer écourter la durée du démarrage.

Je vous remercie pour l'intérêt que vous avez apporté à mon sujet. Comme il ne s'agit pas d'un point bloquant, je vais le traiter avec une moindre priorité.

Je vous souhaite de bonnes fêtes de Pâques à tous, que vous soyez ou non croyant un quelque religion que ce soit.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#14 Le 03/04/2021, à 12:47

MicP

Re : [Contournement] Attente exagérée au démarrage

Après avoir lu les docs dont j'ai donné les liens plus celle là : https://wiki.archlinux.org/index.php/mkinitcpio
je me demande si ça n'est pas le fichier initramfs qui lance ces vérifications,
étant donné que c'est lui qui démarre le système depuis la RAM
avant que le véritable (celui qui est sur disque) système de fichiers racine ne soit monté …

Peut-être qu'en le recréant, il prendrait en compte les valeurs spécifiées
dans le fichier /etc/fstab et celles qui ont été données avec tune2fs

Dernière modification par MicP (Le 03/04/2021, à 12:52)

Hors ligne

#15 Le 03/04/2021, à 18:44

Arbiel

Re : [Contournement] Attente exagérée au démarrage

@MicP

Tu as raison. Il y a de fortes chances que la vérification des disques soit lancée par initrd.img.

Il y a quelques instants, en démarrant mon PC, j'ai remarqué que l'animation présentée sur l'écran, à savoir 3 petites comètes qui tournent en rond en se poursuivant l'une l'autre, apparaît dès que initrd.img me répercute le premier message créé par cryptsetup sur l'ouverture effective de mon premier volume logique chiffré. Le second message de cryptsetup relatif à mon second volume logique chiffré disparaît peu après.

Cette animation, de son côté, se poursuit presque jusqu'à ce que le système me donne la main, c'est-à-dire pendant tout le temps qu'apparaît le message m'informant que je peux stopper le contrôle par Ctrl+C.

J'ai fait un test en commentant les 2 derniers paramètres des lignes de fstab, ce qui revient à annuler le contrôle des systèmes de fichiers. J'ai correctement vu apparaître les messages de cryptsetup avec l'animation. La disparition du second message de cryptsetup m'a semblé survenir beaucoup plus tardivement. Le message indiquant le contrôle des systèmes de fichiers n'est pas apparu. Mais le PC n'a pas démarré après une attente de plusieurs minutes, et l'animation est restée active pendant toute la durée de cette attente. Peut-être mon fichier fstab modifié était-il erroné, mais je n'ai pas insisté, une telle modification ne pouvant être la solution au problème.

Par ailleurs, j'ai commenté dans /etc/default/cryptdisks la ligne
CRYPTDISKS_CHECK=blkid
Sans aucun effet, ce qui n'est pas surprenant car cette ligne n'aurait d'impact qu'avec l'option check dans les lignes de crypttab, ce qui n'est pas le cas.

Tu me proposes de recréer mon initrd.img. Je doute un peu que les paramètres relatifs au contrôle soit mémorisés dans ce fichier car quiconque les modifierait devrait le recréer, et une telle obligation serait indiquée dans la page man de tune2fs. La seule mention de initrd.img dans cette page de manuel est la suivante :

man tune2fs a écrit :

              On  some distributions, such as Debian, if an initial ramdisk is
              used, the initrd scripts will automatically convert an ext2 root
              filesystem  to  ext3  if  the /etc/fstab file specifies the ext3
              filesystem for the root filesystem in order to  avoid  requiring
              the  use  of  a rescue floppy to add an ext3 journal to the root
              filesystem.

Je vais peut-être ouvrir un ticket dans launchpad car l'absence de prise en compte du délai entre vérifications des systèmes de fichiers n'est pas normale.

En attendant, je vais mettre ce problème en attente car je dois d'abord mettre définitivement en service la 20.04 sur mon nouvel ordinateur. Des tâches plus urgentes m'attendent après cette mise en service.

Bien sûr tous les commentaires restent les bienvenus, mais la prise en compte de ces commentaires par mes soins risque d'être plus tardive.

Merci encore à toi, et à vous tous pour votre participation à cette discussion, que je laisse ouverte.

Arbiel


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#16 Le 09/04/2021, à 11:22

iznobe

Re : [Contournement] Attente exagérée au démarrage

Salut , pour en revenir a ton probleme , jette un oeil ici , cqfd93 c ' est retrouvé avec le meme soucis : https://forum.ubuntu-fr.org/viewtopic.php?id=2063535

il se peut donc que ca te donnes des indications .
A priori le soucis qu ' une verifiaction se lancait a chaque demarrage etait du au fait que tunes2fs etait configuré pour verifier une partition de swap , bien sur cela provoquait une erreur et donc tune2fs relancait une verif a chaque demarrage a cause de cette erreur ou du fait que la partition n ' etait pass marqué comme analysé depuis plus de temps que ce  qu ' il etait programmé pour le faire .

donc verifie que tu n' aies pas configuré dans tune2fs une partition que tu aurais soit modifié soit effacé ou bien transformé en swap ou un truc bizzare .


retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .

Hors ligne

#17 Le 09/04/2021, à 11:54

ylag

Re : [Contournement] Attente exagérée au démarrage

Bonjour,

Arbiel au #15 a écrit :

Tu as raison. Il y a de fortes chances que la vérification des disques soit lancée par initrd.img.

Pour info, il y aurait ceci dans le fichier initrd.img du noyau courant sur un Ubuntu 18.04 :

yvan@yvan-maison:~$ lsinitramfs /boot/initrd.img-4.15.0-140-generic |grep -i fsck
sbin/e2fsck
sbin/fsck.ext4
sbin/fsck
yvan@yvan-maison:~$

Pas de 20.04 disponible pour vérifier sur ma machine, mais ça pourrait être semblable ?

Peut-être essayer de reconstruire le initrd.img une fois les modifs faites avec tune2fs :

sudo update-initramfs -u

...avant de redémarrer ?

A+

Dernière modification par ylag (Le 09/04/2021, à 15:04)

Hors ligne

#18 Le 09/04/2021, à 13:45

ylag

Re : [Contournement] Attente exagérée au démarrage

Bonjour,

Une discussion à ce sujet sur Launchpad; ça semble concerner le paquet casper : Bug #1875548

A+

Dernière modification par ylag (Le 09/04/2021, à 13:46)

Hors ligne

#19 Le 09/04/2021, à 15:01

cqfd93

Re : [Contournement] Attente exagérée au démarrage

Bonjour,

ylag a écrit :

Une discussion à ce sujet sur Launchpad; ça semble concerner le paquet casper : Bug #1875548

Ce bug concerne la version live si j'ai bien tout compris (j'ai remarqué ça aussi mais comme je ne démarre pas très souvent de session live, ça ne m'a pas trop gênée). Dans le cas d'Arbiel et le mien, c'est bien un problème avec la version installée.


cqfd93

Hors ligne

#20 Le 09/04/2021, à 15:11

ylag

Re : [Contournement] Attente exagérée au démarrage

@cqfd93:

Bonjour,

Comme méthode de contournement, peut-être essayer l'option fsck.mode=skip dans la ligne de commande au démarrage ?

A+

Dernière modification par ylag (Le 09/04/2021, à 15:13)

Hors ligne

#21 Le 09/04/2021, à 15:13

Coeur Noir

Re : [Contournement] Attente exagérée au démarrage

À peu près idem sur une 20.04 :

django@ASGARD:~$ lsinitramfs /boot/initrd.img-5.4.0-70-generic | grep -i fsck
usr/sbin/e2fsck
usr/sbin/fsck
usr/sbin/fsck.ext4
django@ASGARD:~$ 

DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#22 Le 09/04/2021, à 15:18

cqfd93

Re : [Contournement] Attente exagérée au démarrage

Et voilà chez moi (20.04.2) :

moi@moi-lenovo:~$ lsinitramfs /boot/initrd.img-5.8.0-48-generic | grep -i fsck
usr/sbin/e2fsck
usr/sbin/fsck
usr/sbin/fsck.ext4
moi@moi-lenovo:~$ 

cqfd93

Hors ligne

#23 Le 09/04/2021, à 15:23

cqfd93

Re : [Contournement] Attente exagérée au démarrage

Bonjour,

ylag a écrit :

Comme méthode de contournement, peut-être essayer l'option fsck.mode=skip dans la ligne de commande au démarrage ?

J'ai supprimé cette partition swap devenue inutile mais au premier redémarrage, y'a encore eu une vérification de disque (sans précision duquel). Si ça se reproduit, j'en reparlerai dans mon fil, pas la peine de squatter celui d'Arbiel wink


cqfd93

Hors ligne

#24 Le 09/04/2021, à 16:13

ylag

Re : [Contournement] Attente exagérée au démarrage

Bonjour,

cqfd93 a écrit :

...pas la peine de squatter celui d'Arbiel

Arbiel pourrait aussi tenter la suggestion du commentaire #20 ?

A+

Hors ligne

#25 Le 09/04/2021, à 20:00

Arbiel

Re : [Contournement] Attente exagérée au démarrage

Bonsoir à tous

Dans ce qui suit, j'utilise essentiellement le terme «volume logique» puisque j'utilise LVM dans toutes mes configurations. Bien évidemment le terme «partition» pourrait lui être substitué hors utilisation de LVM.

Par ailleurs, j'ai installé deux systèmes, un système de secours entièrement contenu dans un volume logique, et un système opérationnel, dont deux volumes logiques sont chiffrés, la racine et mon répertoire personnel.

Pour en revenir au sujet de la présente discussion, j'ai progressé dans l'analyse du problème. En fait, il y a plusieurs problèmes, ou plutôt, plusieurs erreurs.

Tout d'abord, le message qui indique la vérification des systèmes est erroné. Il ne s'agit pas de vérifications des systèmes de fichiers, mais tout me laisse penser qu'il s'agit de contrôle de mon LVM, ce qui est tout différent. Ceci explique entre autres que les informations contenues dans les systèmes de fichiers ne soient pas prises en compte, et bien évidemment pas modifiées à chaque démarrage puisque le contrôle n'est pas effectué par fsck ni par les gestionnaires spécialisées (fsck.fstype). La nouvelle exécution de update-initramfs que j'ai réalisée n'a absolument rien changé. Je m'en doutais, mais j'ai voulu m'en assurer.

Et il ne s'agit vraisemblablement pas non plus du contrôle des partitions chiffrées puisque le même message apparaît au démarrage de mon système de secours avec cependant un petit doute dont j'explique la raison vers la fin de la présente intervention.

Cette première erreur, qui peut éventuellement provenir d'une erreur de traduction, m'a conduit sur une fausse piste sur laquelle je vous ai malencontreusement entraînés. Il n'en reste pas moins que le message aurait dû disparaître beaucoup plus rapidement.

L'autre erreur est plutôt une incohérence dans la gestion des volumes chiffrés. Elle est apparue avec l'introduction de systemd dans la 16.04.

Autant que j'aie pu comprendre, pour que le déchiffrement des volumes chiffrés soit effectué par l'initrd.img, ce qui est essentiel, il faut utiliser le paramètre «initramfs» dans les options de crypttab :

philippe-rhizot /dev/mapper/philippe-rhizot_l /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/philippe-rhizot:1 luks,initramfs,tries=1,keyscript=/lib/cryptsetup/scripts/passdev
philippe-ophelia /dev/mapper/philippe-ophelia_l /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/philippe-ophelia:1 luks,initramfs,tries=1,keyscript=/lib/cryptsetup/scripts/passdev

Certes, mais :

man crypttab a écrit :

       initramfs
           The initramfs hook processes the root device, any resume devices
           and any devices with the initramfs option set. These devices are
           processed within the initramfs stage of boot. As an example, that
           allows the use of remote unlocking using dropbear.

           This option is specific to the Debian crypttab format. It's not
           supported by systemd.

Cette incohérence m'a conduit à ne pas installer la 16.04. Elle se soldait par un blocage. Je n'en ai identifié la raison que lorsque j'ai décidé d'installer la 18.04 à l'approche de la fin de vie de la 16.04.

Après la récente installation de la 20.04 sur mon nouveau PC, aussi bien de mon système de secours que de mon système opérationnel, la lenteur du démarrage m'a surpris, mais le message sur le contrôle des systèmes de fichiers m'a incité à patienter. Je me suis donc focalisé sur ce message.

Ne trouvant aucune explication, j'ai analysé le journal de systemd pour y trouver les informations suivantes :

arbiel@arbiel-NK3S-8-S4:~$ grep waiting '/home/arbiel/Bureau/ubuntu_forum/journalctl.txt' 
avril 06 14:16:05 arbiel-NK3S-8-S4 systemd[1]: Timed out waiting for device /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/philippe-ophelia:1.
avril 06 14:16:05 arbiel-NK3S-8-S4 systemd[1]: Timed out waiting for device /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.ckf/philippe-rhizot:1.
avril 06 14:16:05 arbiel-NK3S-8-S4 acpid[1387]: waiting for events: event logging is off
arbiel@arbiel-NK3S-8-S4:~$ 

Exactement comme il y a deux ans. J'ai appliqué le même remède :
1) j'ai enregistré les deux lignes de crypttab présentées plus haut dans un fichier autre que crypttab, disons crypttab+
2) j'ai tout effacé de crypttab
3) je monte par fstab le fichier crypttab+ sur crypttab

Cette dernière opération est nécessaire pour qu'une éventuelle exécution automatique de update-initramfs produise un fichier initrd.img correct sans que j'aie à m'en soucier.

Il reste encore un point à élucider.

Pour faciliter l'ouverture par cryptdisks_start des volumes chiffrés lorsque je suis amené à utiliser mon système de secours, j'y ai initialement défini un fichier crypttab. Comme indiqué précédemment, j'ai constaté l'affichage du message sur le contrôle des systèmes de fichiers, et sa disparition beaucoup plus rapide. Prenant conscience du problème, j'ai depuis effectué les deux seules premières phases de la solution que je viens de décrire, deux premières phases pour éviter la création d'un initrd.img inapproprié. Je n'ai pas investigué davantage. Je monterai à la main crypttab+ sur crypttab, à moins qu'il me suffise de supprimer le paramètre «initramfs».

C'est le fait d'avoir créé un fichier crypttab dans mon système de secours, qui me fait hésiter sur l'objet réel du contrôle, LVM ou mes volumes chiffrés.

J'ai été un peu long, et espère avoir été clair.

Je vous remercie pour votre attention.

Arbiel

[Édit]
Je viens de créer un fichier /etc/crypttab dans mon système de secours, dans lequel j'ai remplacé «initramfs» par «noauto». Au démarrage, aucun message de contrôle du prétendu système de fichiers n'apparaît. Il semblerait donc qu'il s'agit d'un contrôle des volumes logiques chiffrés et non du LVM puisque la modification que je viens d'effectuer n'y a aucun impact.
[/Édit]

Dernière modification par Arbiel (Le 09/04/2021, à 21:27)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne