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.

#76 Le 12/04/2021, à 15:29

Arbiel

Re : 20.04 : Vérification des disques à chaque démarrage

Chez moi, fsck=skip fait disparaître le message. Ce n'est ainsi certainement pas initrd.img qui effectue ce contrôle.

Pour ce qui concerne les durées d'exécution vues pas systemd ;
(avec fsck=skip)

arbiel@arbiel-NK3S-8-S4:~$ sudo systemd-analyze
Startup finished in 3.936s (firmware) + 9.217s (loader) + 7.914s (kernel) + 25.134s (userspace) = 46.203s 
graphical.target reached after 25.122s in userspace
arbiel@arbiel-NK3S-8-S4:~$

sans fsck=skip

arbiel@arbiel-NK3S-8-S4:~$ sudo systemd-analyze
Startup finished in 3.931s (firmware) + 5.814s (loader) + 7.942s (kernel) + 25.105s (userspace) = 42.793s 
graphical.target reached after 25.095s in userspace
arbiel@arbiel-NK3S-8-S4:~$ 

J'ai ajouté une ligne dans le menu grub de sorte que je peux, au démarrage, de demander ou non de sauter fsck. L'écart, très important, pour la durée de loader (s'agit-il d'initrd.img ?) peut-il être dû à mon temps de réaction pour la sélection de la seconde ligne ( fsck=skip) ?

Je vais faire encore quelques chronométrages.

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

#77 Le 12/04/2021, à 16:08

ylag

Re : 20.04 : Vérification des disques à chaque démarrage

Bonjour,

Arbiel a écrit :

Chez moi, fsck=skip fait disparaître le message.

La syntaxe de l'option devrait plutôt être : fsck.mode=skip ?

A+

Hors ligne

#78 Le 12/04/2021, à 16:53

Arbiel

Re : 20.04 : Vérification des disques à chaque démarrage

Oui, je me suis trompé en rédigeant mon intervention précédente. C'est bien

arbiel@arbiel-NK3S-8-S4:~$ grep fsck /boot/grub/grub.cfg
menuentry 'Ubuntu avec fsck.mode=skip' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-5ab1950c-cd24-42d3-a4a6-256985877370' {
	linux	/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro  quiet splash $vt_handoff fsck.mode=skip
arbiel@arbiel-NK3S-8-S4:~$ 

Je viens de redémarrer avec fsck.mode=skip. Les durées sont les suivantes

arbiel@arbiel-NK3S-8-S4:~$ sudo systemd-analyze
Startup finished in 3.980s (firmware) + 7.682s (loader) + 7.632s (kernel) + 26.435s (userspace) = 45.730s 
graphical.target reached after 26.405s in userspace
arbiel@arbiel-NK3S-8-S4:~$ 

On retrouve des durées comparables avec l'exécution précédente.

Dans mon cas, la suppression de la vérification au démarrage n'accélère pas vraiment la procédure. Mais ces différences de durée du quelques secondes ne sont pas sensibles à l'utilisateur.
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

#79 Le 12/04/2021, à 16:56

Coeur Noir

Re : 20.04 : Vérification des disques à chaque démarrage

Pour les « installations » ( donc pas les mises à niveau ) vous étiez passés par
⋅ « autre chose » en ciblant manuellement des partitions préalablement créées
⋅ ou par une des options ± automatique de l'installateur ?

L'idée derrière cette question c'est : on sait qu'Ubiquity ( l'installateur ) fait très souvent du caca dès qu'il s'agit d'autre chose que du 100% UEFI.
Comme créer des partitions esp/efi alors que pas besoin en uefi-mode-legacy ou sur vieux bios.
Ou installer en UEFI alors que la table de partition du disque de destination n'est pas GPT.

Ça fait donc des installations ± incohérentes : ne sont-ce pas ces potentielles incohérences qui « déclenchent » ces vérifications de système de fichiers au démarrage ?


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

Hors ligne

#80 Le 12/04/2021, à 17:21

erresse

Re : 20.04 : Vérification des disques à chaque démarrage

Comme apparemment le phénomène semble se produire sur des systèmes fraîchement installés comme sur des systèmes mis à niveau, sur des disque au format GPT comme au format MBR, sur des installations en mode UEFI comme en mode legacy, le mystère reste entier pour l'heure...
Pour ma part, j'ai installé une version 20.04 fraîche sur mes deux machines, un desktop et un portable, et je ne rencontre pas ce problème de vérification systématique des volumes au démarrage, ni sur l'une ni sur l'autre.
Précisons que mes machines sont toutes les deux en legacy et les disques en MBR, très très classique, donc...
Sur ces machines, j'ai une variante Ubuntu-Mate 20.04 et également (pour le fun) une WindowFX qui est un melting-pot basé sur Linux Mint (et donc aussi sur Ubuntu 20.04) et une tripotée de dépôts supplémentaires divers.
Lorsque je démarre l'un ou l'autre de ces systèmes, je ne rencontre pas le problème de vérification des volumes, sauf au bout de plusieurs redémarrages, suivant le cycle normal.
Alors je me pose la question (elle a peut-être déjà été posée mais la conversation est déjà bien longue...) : Quelle est la variante de ceux qui ont ce problème ? Est-ce que cela est constaté sur plusieurs saveurs ou sur une seule ?

Dernière modification par erresse (Le 12/04/2021, à 17:22)


Plus de 50 ans d'informatique, ça en fait des lignes de commandes en console, mais on n'avait pas le choix...
Excellente raison pour, aujourd'hui qu'on le peut, utiliser au maximum les INTERFACES GRAPHIQUES !
Important : Une fois résolu, pensez à clore votre sujet en ajoutant [Résolu] devant le titre du 1er message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.

Hors ligne

#81 Le 12/04/2021, à 17:32

cqfd93

Re : 20.04 : Vérification des disques à chaque démarrage

erresse a écrit :

Quelle est la variante de ceux qui ont ce problème ? Est-ce que cela est constaté sur plusieurs saveurs ou sur une seule ?

moi@moi-lenovo:~$ echo "${XDG_CURRENT_DESKTOP}"
Unity:Unity7:ubuntu
moi@moi-lenovo:~$ 

cqfd93

Hors ligne

#82 Le 12/04/2021, à 17:37

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

Pour mon cas voici :

iznobe@iznobe-PC:~$ lsb_release -id
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
iznobe@iznobe-PC:~$ echo "${XDG_CURRENT_DESKTOP}"
ubuntu:GNOME
iznobe@iznobe-PC:~$

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

Hors ligne

#83 Le 12/04/2021, à 17:51

erresse

Re : 20.04 : Vérification des disques à chaque démarrage

@cqfd93 et iznobe : donc, pour vous deux, c'est Ubuntu version "de base", semble-t-il, même si l'interface est différente (Gnome et Unity).
isnobe, je vois que ta signature indique Ubuntu et aussi LM (Linux Mint ?). Si c'est bien Linux Mint, constates-tu le même problème lorsque tu démarres ce système aussi ?


Plus de 50 ans d'informatique, ça en fait des lignes de commandes en console, mais on n'avait pas le choix...
Excellente raison pour, aujourd'hui qu'on le peut, utiliser au maximum les INTERFACES GRAPHIQUES !
Important : Une fois résolu, pensez à clore votre sujet en ajoutant [Résolu] devant le titre du 1er message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.

Hors ligne

#84 Le 12/04/2021, à 17:52

nany

Re : 20.04 : Vérification des disques à chaque démarrage

cqfd93 a écrit :
echo "${XDG_CURRENT_DESKTOP}"
iznobe a écrit :
echo "${XDG_CURRENT_DESKTOP}"
printenv XDG_CURRENT_DESKTOP

Maître Capello
tongue

Hors ligne

#85 Le 12/04/2021, à 18:04

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

@erresse
comme je l' expliquait je ne sais plus trop si c ' est dans ce fil ou un autre , sous LM qui est bien linux mint je ne constate aucun probleme sauf , si je lance un redemarrage d ' ubuntu , dans ce cas j ' ai un arret dans la sequence de demarrage sur :
scan for BTRFS file system d ' environ 15 sec , puis ca reprend comme si  de rien n ' etait .
si je redemarre de LM sur LM ou de windows sur LM , pas de pb . je n' ai pas de partition en btrfs  sur aucun de mes disques .

@nany quelle difference entre les 2 commandes ?

Dernière modification par iznobe (Le 12/04/2021, à 18:09)


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

Hors ligne

#86 Le 12/04/2021, à 18:09

Arbiel

Re : 20.04 : Vérification des disques à chaque démarrage

Pour ma part, j'ai installé un tout nouveau système avec «autre chose» sur un disque au format GPT et en UEFI.

arbiel@arbiel-NK3S-8-S4:~$ printenv XDG_CURRENT_DESKTOP
ubuntu:GNOME
arbiel@arbiel-NK3S-8-S4:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
arbiel@arbiel-NK3S-8-S4:~$ 

J'ai démarré cette fois avec fsck.mode=force. Voila ce que j'obtiens

arbiel@arbiel-NK3S-8-S4:~$ sudo systemd-analyze
Startup finished in 3.961s (firmware) + 9.963s (loader) + 8.602s (kernel) + 30.445s (userspace) = 52.973s 
graphical.target reached after 30.434s in userspace
arbiel@arbiel-NK3S-8-S4:~$ 

Une durée dans «userspace» (que cela représente-t-il ?) sensiblement plus longue.

Avant de démarrer, dans /etc/fstab, j'ai mis à 0 le 6e champ de mes volumes logiques psilos et gumnon.

arbiel@arbiel-NK3S-8-S4:~$ sup_nul /etc/fstab | grep -v bind | grep -E "(psilos|gumnon)"
/dev/mapper/philippe-psilos /home/arbiel/Documents/psilos ext4 defaults,user,exec  0 0
/dev/mapper/philippe-gumnon /home/arbiel/Documents/gumnon ext2 defaults,user,exec  0 0
arbiel@arbiel-NK3S-8-S4:~$ 

Ils n'ont pas été vérifiés, contrairement à tous les autres, commme on le constate ci-dessous :
(J'ai défini comme alias «g» pour «grep» et «s» pour sudo.)

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/arbiel/.bash_aliases
Last mount time:          Mon Apr 12 18:00:49 2021
Last write time:          Mon Apr 12 18:00:49 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021

/dev/philippe/xavier
Last mounted on:          /boot
Last mount time:          Mon Apr 12 18:00:47 2021
Last write time:          Mon Apr 12 18:00:47 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021

/dev/philippe/usr
Last mounted on:          /usr
Last mount time:          Mon Apr 12 18:00:43 2021
Last write time:          Mon Apr 12 18:00:42 2021
Last checked:             Mon Apr 12 18:00:42 2021
Next check after:         Wed May 12 18:00:42 2021

/dev/philippe/gumnon
Last mounted on:          /home/arbiel/Documents/gumnon
Last mount time:          Mon Apr 12 18:00:48 2021
Last write time:          Mon Apr 12 18:00:48 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:          /etc/crypttab
Last mount time:          Mon Apr 12 18:00:48 2021
Last write time:          Mon Apr 12 18:00:48 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:          Mon Apr 12 18:00:52 2021
Last write time:          Mon Apr 12 18:00:52 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021

/dev/philippe/phortos
Last mounted on:          /home/arbiel/Téléchargements
Last mount time:          Mon Apr 12 18:00:50 2021
Last write time:          Mon Apr 12 18:00:50 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021

/dev/philippe/biblioi
Last mounted on:          /home/arbiel/Bureau/Biblioi
Last mount time:          Mon Apr 12 18:00:48 2021
Last write time:          Mon Apr 12 18:00:48 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021

/dev/philippe/melopoi
Last mounted on:          /home/arbiel/Bureau/Musique
Last mount time:          Mon Apr 12 18:00:51 2021
Last write time:          Mon Apr 12 18:00:51 2021
Last checked:             Mon Apr 12 18:00:47 2021
Next check after:         Wed May 12 18:00:47 2021
arbiel@arbiel-NK3S-8-S4:~$

alors que, le 3 avril, constatant l'affichage du message de vérification à chaque démarrage, j'ai obtenu des informations qui ne correspondent pas à ce constat. Le code ci-dessous montre que les volumes ont été montés le jour même, et vérifiés quelques jours auparavant, et non pas lors du démarrage courant comme le laisse croire le message.

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:~$ 

Il semble donc que l'option de la commande linux de grub.cfg porte sur le traitement de /etc/fstab alors que tel n'était pas le cas dans mes démarrages de la semaine dernière. Pourtant, le message affiché sur l'écran est apparemment le même.

Arbiel

Dernière modification par Arbiel (Le 12/04/2021, à 18:12)


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

#87 Le 12/04/2021, à 18:25

Coeur Noir

Re : 20.04 : Vérification des disques à chaque démarrage

Je préférerais comparer les « partitionnements » des disques entre des machines où y'a pas la demande de check systématique / y'a la demande systématique.

En voilà 2 - 20.04 - où je n'ai pas de check systématique :

django@ASGARD:~$ sudo parted -l
[sudo] Mot de passe de django : 
Modèle : ATA WDC WD10EZEX-00B (scsi)
Disque /dev/sda : 1000GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin    Taille  Type     Système de fichiers  Drapeaux
 1      1049kB  999GB  999GB   primary  ext4


Modèle : ATA Samsung SSD 840 (scsi)
Disque /dev/sdb : 120GB
Taille des secteurs (logiques/physiques) : 512B/512B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  40,0GB  40,0GB  primary   ext4                 démarrage
 2      40,0GB  120GB   80,0GB  extended
 5      40,0GB  80,0GB  40,0GB  logical   ext4
 6      80,0GB  120GB   40,0GB  logical   ext4


django@ASGARD:~$ 

↑ ça c'est une Budgie, à disques mbr/msdos parce que, euh, pourquoi pas et bios UEFI en mode legacy
A connu mises à niveau 18.04 → 19.10 → 20.04


palace0@POSEO-SRV:/$ sudo parted -l
Modèle : ATA WDC WD30EFRX-68E (scsi)
Disque /dev/sda : 3001GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom        Drapeaux
 1      1049kB  68,2MB  67,1MB                       bios_grub  bios_grub
 2      68,2MB  4359MB  4291MB  ext4                 BOOT       démarrage, esp
 3      4360MB  25,8GB  21,5GB  ext4                 SYSTEM
 4      25,8GB  3001GB  2975GB  ext4                 DATA


Modèle : ATA WDC WD30EFRX-68E (scsi)
Disque /dev/sdb : 3001GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom     Drapeaux
 1      1049kB  3001GB  3001GB  ext4                 BACKUP


palace0@POSEO-SRV:/$ 

Et ça ↑ une Xubuntu 20.04 à disques GPT ( car > 2To ) mais bios old-school pas du tout UEFI.
MAIS comme c'est du GPT :
⋅ une première petite partition à drapeau bios_grub préconisée dans https://doc.ubuntu-fr.org/gpt#creer_une … _bios-boot
⋅ et une partition boot/esp
A connu récemment mise à niveau 18.04 → 20.04.

_________________________

printenv XDG_CURRENT_DESKTOP

et pourquoi pas

echo $DESKTOP_SESSION

?

Dernière modification par Coeur Noir (Le 12/04/2021, à 18:30)


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

Hors ligne

#88 Le 12/04/2021, à 21:12

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

Pour info j ' ai ajouté l ' option fsck.mode=skip dans /etc/defaut/grub redemarrer hors mis que le disque n' est pas scanner j ' avais toujours le meme message ...

Enfin bref le probleme n ' est pas là , j ' ai fait ( je n' ai pas mis celles avant le redemarrage volontairement ) :

iznobe@iznobe-PC:~$ cat /var/log/syslog | grep error
Apr 12 22:00:15 iznobe-PC gnome-shell[43412]: gnome-shell: Fatal IO error 4 (Appel système interrompu) on X server :0.
Apr 12 22:00:15 iznobe-PC evolution-alarm[43668]: evolution-alarm-notify: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.
Apr 12 22:00:15 iznobe-PC gnome-terminal-[90754]: gnome-terminal-server: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.
Apr 12 22:00:15 iznobe-PC update-notifier[44838]: update-notifier: Fatal IO error 11 (Ressource temporairement non disponible) on X server :0.
Apr 12 22:01:40 iznobe-PC systemd[1]: Condition check resulted in Process error reports when automatic reporting is enabled (file watch) being skipped.
Apr 12 22:01:40 iznobe-PC kernel: [   37.736671] EXT4-fs (sdd2): re-mounted. Opts: errors=remount-ro
Apr 12 22:01:48 iznobe-PC snapd[1355]: stateengine.go:150: state ensure error: Post https://api.snapcraft.io/v2/snaps/refresh: dial tcp: lookup api.snapcraft.io: no such host
Apr 12 22:01:53 iznobe-PC /usr/lib/gdm3/gdm-x-session[1629]: #011(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
iznobe@iznobe-PC:~$ 

cette ligne m ' interpelle quelque peu ...
Apr 12 22:01:40 iznobe-PC kernel: [   37.736671] EXT4-fs (sdd2): re-mounted. Opts: errors=remount-ro
sachant que sdd2 est la partition racine de mon ubuntu .

Pourtant il semble que la partition " / " est " writable " :

iznobe@iznobe-PC:~$ ls -la /
total 112
drwxr-xr-x  26 root   root    4096 avril 12 10:29 .
drwxr-xr-x  26 root   root    4096 avril 12 10:29 ..
drwxr-xr-x   2 root   root    4096 avril 10 17:12 bin
drwxr-xr-x   4 root   root    4096 avril 10 17:42 boot
drwx------   2 root   root    4096 sept. 11  2020 .cache
drwxrwxr-x   2 root   root    4096 janv. 26  2020 cdrom
drwxr-xr-x  21 root   root    4740 avril 12 22:01 dev
drwxr-xr-x 137 root   root   12288 avril 12 10:22 etc
drwxr-xr-x   4 root   root    4096 avril 15  2020 home
lrwxrwxrwx   1 root   root      32 mars  30 18:20 initrd.img -> boot/initrd.img-5.4.0-70-generic
lrwxrwxrwx   1 root   root      32 mars  30 18:20 initrd.img.old -> boot/initrd.img-5.4.0-47-generic
drwxr-xr-x  22 root   root    4096 mars  30 19:22 lib
drwxr-xr-x   2 root   root    4096 avril 11 10:40 lib32
drwxr-xr-x   2 root   root    4096 mars  30 19:09 lib64
drwx------   2 root   root   16384 avril 20  2019 lost+found
drwxr-xr-x  15 iznobe iznobe  4096 avril 11 17:22 media
drwxr-xr-x   5 root   root    4096 mars  30 15:08 mnt
drwxr-xr-x   3 root   root    4096 mai   19  2015 opt
dr-xr-xr-x 422 root   root       0 avril 12 22:00 proc
drwx------   7 root   root    4096 avril 11 14:07 root
drwxr-xr-x  41 root   root    1100 avril 12 22:02 run
drwxr-xr-x   2 root   root   12288 avril 10 17:12 sbin
drwxr-xr-x  10 root   root    4096 mars  30 20:32 snap
drwxr-xr-x   2 root   root    4096 janv. 26  2020 srv
dr-xr-xr-x  13 root   root       0 avril 12 22:00 sys
drwxrwxrwt  22 root   root     460 avril 12 22:15 tmp
drwxr-xr-x  13 root   root    4096 avril 11 10:44 usr
drwxr-xr-x  14 root   root    4096 févr. 10  2019 var
lrwxrwxrwx   1 root   root      29 mars  30 18:20 vmlinuz -> boot/vmlinuz-5.4.0-70-generic
lrwxrwxrwx   1 root   root      29 mars  30 18:20 vmlinuz.old -> boot/vmlinuz-5.4.0-47-generic
iznobe@iznobe-PC:~$

Dernière modification par iznobe (Le 12/04/2021, à 21:28)


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

Hors ligne

#89 Le 12/04/2021, à 22:28

Coeur Noir

Re : 20.04 : Vérification des disques à chaque démarrage

@Iznobe

[   37.736671] EXT4-fs (sdd2): re-mounted. Opts: errors=remount-ro

Là il ne s'agit ni d'un [ warning ] ni d'une [ error ].
La ligne apparaît car elle contient le mot errors qui est dans ce cas une des options normales du montage de la racine système ( en cas d'erreurs elle est remontée en read-only ).

par contre

drwxr-xr-x  15 iznobe iznobe  4096 avril 11 17:22 media

est censé appartenir à root mais ça n'a probablement rien à voir avec le sujet initial.

@tous

sudo parted -l

en précisant votre contexte « bios » ( 100% UEFI, uefi-MAIS-mode-legacy, pas uefi du tout ).

Dernière modification par Coeur Noir (Le 12/04/2021, à 22:38)


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

Hors ligne

#90 Le 12/04/2021, à 22:45

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

@Coeur Noir , je crois que je fatigue ...
pour media je change ca desuite merci !

iznobe@iznobe-PC:~$ sudo parted -l
Modèle : ATA ST4000VX000-2AG1 (scsi)
Disque /dev/sda : 4001GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom         Drapeaux
 1      1049kB  3459GB  3459GB  ext4                 Seagate_4T
 3      3459GB  4001GB  542GB   ntfs                 comune      msftdata


Modèle : ATA WDC WD82PURZ-85T (scsi)
Disque /dev/sdb : 8002GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom   Drapeaux
 1      1049kB  7443GB  7443GB  ext4
 2      7443GB  8002GB  559GB   ext4                 SAUV


Modèle : ATA TOSHIBA HDWD130 (scsi)
Disque /dev/sdc : 3001GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom         Drapeaux
 1      1049kB  281GB   281GB   ext4                 home
 3      281GB   315GB   34,0GB  linux-swap(v1)                   swap
 2      315GB   3001GB  2686GB  ext4                 Toshiba_3T


Modèle : ATA ST3500320AS (scsi)
Disque /dev/sdd : 500GB
Taille des secteurs (logiques/physiques) : 512B/512B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Système de fichiers  Nom          Drapeaux
 4      1049kB  269MB   268MB   fat32                             démarrage, esp
 1      269MB   18,9GB  18,6GB  ext4                 L_M_secours
 2      18,9GB  36,7GB  17,8GB  ext4                 Ubuntu
 3      36,7GB  500GB   463GB   ext4                 Sauvegardes


Modèle : ADATA SX8200PNP (nvme)
Disque /dev/nvme0n1 : 512GB
Taille des secteurs (logiques/physiques) : 512B/512B
Table de partitions : gpt
Drapeaux de disque : 

Numéro  Début   Fin    Taille  Système de fichiers  Nom  Drapeaux
 1      1049kB  134GB  134GB   ntfs                      msftdata
 5      134GB   167GB  32,8GB  ext4
 2      499GB   499GB  667MB   ntfs                      caché, diag
 3      499GB   500GB  105MB   fat32                     démarrage, esp
 4      500GB   500GB  561MB   ntfs                      caché, diag


iznobe@iznobe-PC:~$ 

theoriquement passé en mode full EFI maintenant .

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


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

Hors ligne

#91 Le 13/04/2021, à 03:15

Coeur Noir

Re : 20.04 : Vérification des disques à chaque démarrage

Merci pour ce retour.

T'as un disque de 8To ? Garanti à vie j'espère ? lol

Le drapeau boot~esp est sur sdd4, et ton système courant sur sdd2 je suppose.
C'est quoi /dev/nvme0n1 (5) sans drapeau mais en ext4 ?

Puisque tu dis que c'est du 100% UEFI → GPT partout → une partition ESP → ça a l'air « conforme »… et donc cette configuration lance un « check » à chaque démarrage ?
Est-ce qu'un boot-info te confirme que ton installation est bien uefi, ou propose-t-il une suggestion de réparation quelconque ( qui n'est pas forcément à appliquer ) ?

Je n'ai absolument aucune idée de ce qui déconne, hein, là je tente juste de « comparer » des situations en me disant un truc du genre :
⋅ si le système repère que l'installation n'est pas « conforme » c'est peut-être normal qu'il lance un « check »,
⋅ ce « check » est peut une nouveauté récente introduite à partir d'un certain kernel ?
⋅ et comme avec Ubiquity c'est relativement facile d'obtenir une installation certes fonctionnelle mais pas forcément « conforme », avant mise à niveau ça ne posait pas forcément problème ?

Par « conforme » j'entends pile-poil-nickel par rapport au type de bios et l’organisation des partitions :
⋅ 100% UEFI + table de partitions gpt + partition esp~boot
⋅ UEFI-legacy + t.de.p gpt ou mbr + partition esp~boot
⋅ bios old school sur mbr + partitions simples sans esp~boot
⋅ bios old school sur gpt avec une partition « flaggée » bios_grub
…l'air de rien ça fait un paquet de combinaisons possibles et Ubiquity ne les traite pas toutes aussi bien ( et ce n'est que ma compréhension empirique, limitée ).

Maintenant si quelqu'un ici a la certitude absolue que ce check au démarrage ne peut pas avoir techniquement de rapport avec tout ça ( le fait qu'une partition boot~esp est préférablement sur le même disque que le système, ou préférablement en début de disque, la correspondance t.de.p↔type-de-bios, l'utilité avérée ou pas d'une partition bios_grub, etc ) ce serait bien qu'on le sache et on rangera sans regrets mes suppositions dans la catégorie « idées farfelues » big_smile

_________________________

à priori vous n'êtes pas seuls :
https://askubuntu.com/questions/1237389 … stem-check
https://askubuntu.com/questions/1260677 … ect=1&lq=1
…et pas vraiment de solution, sinon réinstaller ( j'ai vu une discussion où virer les paquets orphelins a rendu un boot plus rapide, mais elle n'impliquait pas de fsck au démarrage ).

Dernière modification par Coeur Noir (Le 13/04/2021, à 03:56)


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

Hors ligne

#92 Le 13/04/2021, à 07:45

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

Bonjour , je ne pense pas etre dans une situation conforme et il y a beaucoup de questions d' un coup là roll
normalement j' ai 2 partitions de boot en VFAT une sur SDD4 et une sur NVME0N1P3 ( si je me trompe pas )
plus d' info dans ce lien : https://forum.ubuntu-fr.org/viewtopic.php?id=2063614
ou j ' ai posté mon boot info .
j ' essaie de remettre de l' ordre dans tout ca , puis j' aimerai passer ensuite ubuntu du SDD4 , sur une nouvelle partition de mon nvme j ' ai plein de place dessus .

nvme0n1p5 c ' est ma distrib LM .

Sur le disque nvme la partition ESP est a la fin de cleui-ci , sur SDD elle est placée au debut .
il ya aussi un GRUB sur SDD que boot-repair tente deseperement de reparer sans y parvenir .

ah et j ' oubliais :

iznobe@iznobe-PC:~$ uname -a
Linux iznobe-PC 5.10.29-051029-generic #202104100831 SMP Sat Apr 10 13:02:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
iznobe@iznobe-PC:~$

Apres vu que mon /home est sur une disque ( partition sdc1 ) separé une reinstall de ubuntu directement sur le SSD nvme sera je pense le meilleur choix ,en esperant que les problemes s ' evaporent , au pire je formate completement le SDD apres avoir deplacé les données pour virer le grub , ca devrait le faire non ?

Dernière modification par iznobe (Le 13/04/2021, à 08:20)


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

Hors ligne

#93 Le 13/04/2021, à 08:14

cqfd93

Re : 20.04 : Vérification des disques à chaque démarrage

Bonjour,

Coeur Noir a écrit :

@tous

sudo parted -l

en précisant votre contexte « bios » ( 100% UEFI, uefi-MAIS-mode-legacy, pas uefi du tout ).

Mode legacy

moi@moi-lenovo:~$ sudo parted -l
[sudo] Mot de passe de moi : 
Modèle : ATA ST1000DM003-1ER1 (scsi)
Disque /dev/sda : 1000GB
Taille des secteurs (logiques/physiques) : 512B/4096B
Table de partitions : msdos
Drapeaux de disque : 

Numéro  Début   Fin     Taille  Type      Système de fichiers  Drapeaux
 1      1049kB  50,0GB  50,0GB  primary   ext4                 démarrage
 2      50,0GB  1000GB  950GB   extended
 5      59,0GB  539GB   480GB   logical   ext4
 6      539GB   969GB   430GB   logical   ext4
 7      969GB   1000GB  31,2GB  logical   ext4


moi@moi-lenovo:~$ 

cqfd93

Hors ligne

#94 Le 13/04/2021, à 08:27

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

je vois un point comun aux 3 cas , il semblerait qu ' on est tous une partition /home separée et annoncée  dans le fstab non ?
vu que lors de mon install je n' avais pas implementée le /home separé , je vais commenter la ligne du fstab et redemarrer pour voir .

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


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

Hors ligne

#95 Le 13/04/2021, à 08:32

Rafbor

Re : 20.04 : Vérification des disques à chaque démarrage

Bonjour, j'ai quand même l'impression que seule la partition système est vérifiée.
J'ai la 20.04 sur 2 PC: sur le 1er avec le système sur SSD et home sur HDD, le check ne prend que 4s, c'est vraiment rapide, alors que sur l'autre PC avec 1 seul HDD (home sur partition dédiée) le check est long ~15s.
Avec un SSD, le check passe presque inaperçu.

Dernière modification par Rafbor (Le 13/04/2021, à 08:44)


Xubuntu 22.04 - Mes projets sur Github

Hors ligne

#96 Le 13/04/2021, à 08:59

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

Alors pour info rien a voir avec la partition /home separé ou pas , dommage ca auait été trop facile roll

j ' ai installé :

iznobe@iznobe-PC:~$ sudo apt install showfsck
iznobe@iznobe-PC:~$ sudo showfsck
14/30 mount(s) until fsck for /dev/sda1
***************************
* 3 * /15 mount(s) until fsck for /dev/sdb1
***************************
28/40 mount(s) until fsck for /dev/sdb2
***************************
* -14 * /-1 mount(s) until fsck for /dev/sdc1
***************************
7/25 mount(s) until fsck for /dev/sdc2
***************************
* -52 * /-1 mount(s) until fsck for /dev/sdd1
***************************
***************************
* -50 * /-1 mount(s) until fsck for /dev/sdd2
***************************
22/35 mount(s) until fsck for /dev/sdd3
iznobe@iznobe-PC:~$

on voit clairement que malgré les verifications des FS , le journal n ' est plus a jour ...
je vais tenter un demarrage en live et lancer fsck manuellement pour voir si ca change quelquechose ou pas .

Autre point qui serait possiblement comun : un SSD ?
@arbiel je pense en a un , et toi @cqfd93 ?

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


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

Hors ligne

#97 Le 13/04/2021, à 09:23

cqfd93

Re : 20.04 : Vérification des disques à chaque démarrage

Non, je n'ai pas de ssd.


cqfd93

Hors ligne

#98 Le 13/04/2021, à 09:34

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

OK cqfd93 , on peut a priori ecarter cette piste donc

Bon suite au demarrage en session live et au passage en revue de toutes les partitions ext4 sauf sdb2 et sdc2 avec la commande :

sudo fsck -yfv /dev/sdX 

aucune erreur repertorié , et aucun mauvais secteur  .

je redemarre donc et la je vois apparaitre mon grub en direct .... ca n' a peut etre pas de rapport mais bon curieux alors qu ' habituellement j ' ai l' option uefi firmware en bas .
bref , je lance la meme commande que tout à l'" heure et j obtiens :
iznobe@iznobe-PC:~$ sudo showfsck

[sudo] Mot de passe de iznobe : 
29/30 mount(s) until fsck for /dev/sda1
iznobe@iznobe-PC:~$

alors que toutes mes partitions sont bien montées comme d ' habitude .

j ' en deduis que apres chaque montage du boot il y a comme un truc qui coince ( il ne compte pas les montages ? )
bref du coup je lance :

iznobe@iznobe-PC:~$ sudo umount -a
umount: /run/user/1000: la cible est active.
umount: /home: la cible est active.
umount: /tmp: la cible est active.
umount: /snap/core/10958: la cible est active.
umount: /sys/fs/cgroup/blkio: la cible est active.
umount: /sys/fs/cgroup/unified: la cible est active.
umount: /sys/fs/cgroup: la cible est active.
umount: /run/lock: la cible est active.
umount: /: la cible est active.
umount: /run: la cible est active.
umount: /dev: la cible est active.
iznobe@iznobe-PC:~$

oui j' aurais du faire une par une , mais trop la flemme ...
et j' enchaine avec :

[iznobe@iznobe-PC:~$ sudo mount -a
iznobe@iznobe-PC:~$ sudo showfsck
28/30 mount(s) until fsck for /dev/sda1
***************************
* -1 * /15 mount(s) until fsck for /dev/sdb1
***************************
24/40 mount(s) until fsck for /dev/sdb2
***************************
* -2 * /-1 mount(s) until fsck for /dev/sdc1
***************************
***************************
* 3 * /25 mount(s) until fsck for /dev/sdc2
***************************
***************************
* -3 * /-1 mount(s) until fsck for /dev/sdd1
***************************
***************************
* -2 * /-1 mount(s) until fsck for /dev/sdd2
***************************
18/35 mount(s) until fsck for /dev/sdd3
iznobe@iznobe-PC:~$

comment vous interpretez ces valeurs negatives ?

on dirait qu ' il ne met a jour le journal ou compteur que de sda1 .

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


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

Hors ligne

#99 Le 13/04/2021, à 10:42

nany

Re : 20.04 : Vérification des disques à chaque démarrage

[HS]

iznobe a écrit :

@nany quelle difference entre les 2 commandes ?

Il n’y en a pas. Je voulais juste signaler une commande que je trouve plus élégante. wink
Ceci dit, echo étant une primitive, elle est plus rapide. Mais ça reste invisible pour l’humain car ça se joue au millième de seconde près.
À noter que les accolades sont inutiles (surtout en cette période de pandémie).
Et d’ailleurs,

Coeur Noir a écrit :
printenv XDG_CURRENT_DESKTOP

et pourquoi pas

echo $DESKTOP_SESSION

?

Les deux variables sont intéressantes en fait. Il est possible d’avoir des surprises (multi-environnement par exemple).


Je préconiserais donc :

echo "$DESKTOP_SESSION → $XDG_CURRENT_DESKTOP"

[/HS]

Hors ligne

#100 Le 13/04/2021, à 10:50

iznobe

Re : 20.04 : Vérification des disques à chaque démarrage

Pour info je viens de trouver comment voir les fsck qu ' effectue le systeme au demarrage :

25.409s plymouth-quit-wait.service                                                               
13.372s systemd-journal-flush.service                                                            
 9.523s systemd-fsck@dev-disk-by\x2dlabel-Western_8T.service                                     
 8.382s snapd.service                                                                            
 8.372s networkd-dispatcher.service                                                              
 8.216s dev-sdd2.device                                                                          
 7.811s udisks2.service                                                                          
 6.013s smartmontools.service                                                                    
 5.958s fwupd.service                                                                            
 5.948s accounts-daemon.service                                                                  
 5.777s NetworkManager-wait-online.service                                                       
 5.045s bolt.service                                                                             
 4.830s plymouth-read-write.service                                                              
 4.735s NetworkManager.service                                                                   
 4.717s smbd.service                                                                             
 4.642s nmbd.service                                                                             
 4.284s ModemManager.service                                                                     
 4.159s polkit.service                                                                           
 3.905s avahi-daemon.service                                                                     
 3.777s switcheroo-control.service                                                               
 3.747s thermald.service                                                                         
 3.747s systemd-logind.service                                                                   
 3.746s wpa_supplicant.service                                                                   
 3.698s dev-loop6.device                                                                         
 3.541s postfix@-.service                                                                        
 3.363s dev-loop4.device                                                                         
 3.294s dev-loop1.device                                                                         
 3.073s dev-loop12.device                                                                        
 2.344s dev-loop10.device                                                                        
 2.160s grub-common.service                                                                      
 2.108s gpu-manager.service                                                                      
 1.854s networking.service                                                                       
 1.837s apport.service                                                                           
 1.743s systemd-fsck@dev-disk-by\x2dlabel-Sauvegardes.service                                    
 1.597s nfs-server.service                                                                       
 1.450s apparmor.service                                                                         
 1.424s gdm.service                                                                              
 1.374s systemd-udevd.service                                                                    
 1.350s rsyslog.service                                                                          
 1.161s systemd-fsck@dev-disk-by\x2duuid-7132\x2d44A1.service                                    
 1.012s colord.service                                                                           
 1.008s dns-clean.service                                                                        
  998ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service                                     
  993ms e2scrub_reap.service                                                                     
  742ms nfs-mountd.service                                                                       
  718ms snap-core-10908.mount                                                                    
  691ms systemd-resolved.service                                                                 
  660ms snapd.apparmor.service                                                                   
  611ms proc-fs-nfsd.mount                                                                       
  608ms snap-core18-1997.mount                                                                   
  594ms snap-snap\x2dstore-518.mount                                                             
  573ms snap-core18-1885.mount                                                                   
  557ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service                                    
  547ms keyboard-setup.service                                                                   
  539ms user@1000.service                                                                        
  516ms systemd-modules-load.service                                                             
  437ms snap-gnome\x2d3\x2d26\x2d1604-74.mount                                                   
  423ms rpcbind.service                                                                          
  420ms snap-core-10958.mount                                                                    
  411ms atd.service                                                                              
  407ms pppd-dns.service                                                                         
  399ms apt-daily.service                                                                        
  395ms systemd-sysusers.service                                                                 
  389ms snap-gtk\x2dcommon\x2dthemes-818.mount                                                   
  347ms systemd-udev-trigger.service                                                             
  335ms snap-gtk\x2dcommon\x2dthemes-1514.mount                                                  
  320ms systemd-tmpfiles-setup-dev.service                                                       
  306ms snap-gnome\x2dsystem\x2dmonitor-57.mount                                                 
  282ms upower.service                                                                           
  258ms snap-gnome\x2d3\x2d34\x2d1804-66.mount                                                   
  251ms systemd-random-seed.service                                                              
  250ms snap-gnome\x2d3\x2d26\x2d1604-100.mount                                                  
  241ms snap-gnome\x2d3\x2d34\x2d1804-36.mount                                                   
  239ms systemd-journald.service                                                                 
  238ms nfs-idmapd.service                                                                       
  225ms plymouth-start.service                                                                   
  217ms snapd.seeded.service                                                                     
  211ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
  205ms grub-initrd-fallback.service                                                             
  203ms snap-gnome\x2dsystem\x2dmonitor-157.mount                                                
  168ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service                                     
  160ms run-rpc_pipefs.mount                                                                     
  142ms ifupdown-pre.service                                                                     
  135ms nfs-config.service                                                                       
  135ms systemd-sysctl.service                                                                   
  135ms systemd-timesyncd.service                                                                
  116ms modprobe@drm.service                                                                     
  116ms openvpn.service                                                                          
  111ms systemd-tmpfiles-setup.service                                                           
  111ms kerneloops.service                                                                       
  107ms dev-hugepages.mount                                                                      
  106ms dev-mqueue.mount                                                                         
  103ms sys-kernel-debug.mount                                                                   
  103ms sys-kernel-tracing.mount                                                                 
  100ms kmod-static-nodes.service                                                                
   99ms systemd-tmpfiles-clean.service                                                           
   94ms dev-disk-by\x2duuid-f8a3fadc\x2d7a62\x2d4a73\x2da262\x2df7f50ea7cd83.swap                
   93ms ufw.service                                                                              
   81ms console-setup.service                                                                    
   80ms systemd-fsck@dev-disk-by\x2dlabel-SAUV.service                                           
   72ms systemd-remount-fs.service                                                               
   71ms systemd-update-utmp.service                                                              
   49ms systemd-user-sessions.service                                                            
   47ms home.mount                                                                               
   32ms rtkit-daemon.service                                                                     
   27ms setvtrgb.service                                                                         
   20ms nfs-blkmap.service                                                                       
   16ms user-runtime-dir@1000.service                                                            
   15ms tmp.mount                                                                                
    3ms alsa-restore.service                                                                     
    3ms systemd-update-utmp-runlevel.service                                                     
    3ms postfix.service                                                                          
    1ms sys-fs-fuse-connections.mount                                                            
    1ms snapd.socket                                                                             
    1ms sys-kernel-

a priori il analyse une partition EFI en vfat :

1.161s systemd-fsck@dev-disk-by\x2duuid-7132\x2d44A1.service

je ne pense pas qu ' il devrait .
et celle ligne me parait bizarre aussi :

211ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service

dans mon fstab je n' ai pas de partition avec cet uuid ... qui me parait plus long que la normale .
verif :

iznobe@iznobe-PC:~$ blkid
/dev/nvme0n1p1: LABEL="windows_10" UUID="08CCB0D8CCB0C0EC" TYPE="ntfs" PARTUUID="fa603a68-ea88-11ea-84d7-2cf05d2920f2"
/dev/nvme0n1p2: UUID="D86CD8BF6CD89998" TYPE="ntfs" PARTUUID="b9d0bee1-8f59-4939-aa3d-4fbb7a2826d0"
/dev/nvme0n1p3: UUID="C071-9050" TYPE="vfat" PARTUUID="fa603a69-ea88-11ea-84d7-2cf05d2920f2"
/dev/nvme0n1p4: UUID="0E52DDB352DD9FAF" TYPE="ntfs" PARTUUID="fa603a6a-ea88-11ea-84d7-2cf05d2920f2"
/dev/nvme0n1p5: UUID="eb18366b-2ac9-4a7e-8f93-ba2caa30e90e" TYPE="ext4" PARTUUID="baccdf86-c41b-4282-b346-2bf4044ba210"
/dev/sda1: LABEL="Seagate_4T" UUID="4f8cc284-cd84-4eeb-b412-7539f81664c4" TYPE="ext4" PARTLABEL="Seagate_4T" PARTUUID="c94312f1-6589-402a-b882-1eda4c91df2e"
/dev/sda3: LABEL="comune" UUID="2DF091F12EA57DE1" TYPE="ntfs" PTTYPE="dos" PARTLABEL="comune" PARTUUID="bdedff66-eb2b-4711-ae40-a2220fc152c2"
/dev/sdb1: LABEL="Western_8T" UUID="1db8a5b3-ff12-4d31-9463-b188ffefe43b" TYPE="ext4" PARTUUID="57905315-bfff-4ae2-a429-16b27cd0c835"
/dev/sdb2: LABEL="SAUV" UUID="d9dc9f4e-a24a-4573-9465-13711480f272" TYPE="ext4" PARTLABEL="SAUV" PARTUUID="6701d1a9-a4de-4c6e-8412-bb8855d6eac4"
/dev/sdd1: LABEL="L_M_secours" UUID="8c2cbfbb-8583-4f8d-90d0-ec429d53b2a7" TYPE="ext4" PARTLABEL="L_M_secours" PARTUUID="15721db7-255c-4f9f-8205-ea0ae199b92b"
/dev/sdd2: LABEL="Ubuntu" UUID="52e9b004-bef5-4aa0-9270-be62f84dc53b" TYPE="ext4" PARTLABEL="Ubuntu" PARTUUID="ec17ba2e-937d-4965-85bf-d1e965b1f400"
/dev/sdd3: LABEL="Sauvegardes" UUID="09667412-8a49-4bf0-b02d-d45efdb99453" TYPE="ext4" PARTLABEL="Sauvegardes" PARTUUID="51ed8338-1db9-44e8-aab1-07347c60001a"
/dev/sdd4: UUID="7132-44A1" TYPE="vfat" PARTUUID="c0abc937-5417-4627-9fe7-571d16dba7d7"
/dev/sdc1: LABEL="home" UUID="6dd3be64-2092-4e06-817a-ecc5f1463bda" TYPE="ext4" PARTLABEL="home" PARTUUID="382d4183-c7a2-4732-a8b0-13d32e2d21bb"
/dev/sdc2: LABEL="Toshiba_3T" UUID="6f5e5ed1-b1b5-4bf1-97aa-94495d5fb140" TYPE="ext4" PARTLABEL="Toshiba_3T" PARTUUID="4ef91013-e07c-42a3-bcd6-33d5b7c74b7e"
/dev/sdc3: LABEL="SWAP" UUID="f8a3fadc-7a62-4a73-a262-f7f50ea7cd83" TYPE="swap" PARTUUID="89e4c720-e762-466d-ab35-c51053c280ec"
iznobe@iznobe-PC:~$

EDIT : bon ben l' UUID bizarre correspond a la partition /home .

Reste donc a savoir si c ' est normal que fsck lance une verif sur la partition EFI .
je croyais que fsck ne gerait que les sytemes de fichiers ext  mais d' apres la page : https://doc.ubuntu-fr.org/fsck
il fait aussi les FS vfat .

les compteurs ne change pas apres 5 demarrages :

iznobe@iznobe-PC:~$ sudo showfsck
[sudo] Mot de passe de iznobe : 
27/30 mount(s) until fsck for /dev/sda1
***************************
* -2 * /15 mount(s) until fsck for /dev/sdb1
***************************
23/40 mount(s) until fsck for /dev/sdb2
***************************
* -3 * /-1 mount(s) until fsck for /dev/sdc1
***************************
***************************
* 2 * /25 mount(s) until fsck for /dev/sdc2
***************************
***************************
* -4 * /-1 mount(s) until fsck for /dev/sdd1
***************************
***************************
* -3 * /-1 mount(s) until fsck for /dev/sdd2
***************************
17/35 mount(s) until fsck for /dev/sdd3
iznobe@iznobe-PC:~$

Pour resumer , fsck via systemd analyse toutes les partitions du systeme a chaque demarrage .
et il ne met pas a jour les compteurs de montage demontage des partitions .

vous avez la meme chose ceux qui ont le probleme ?

Dernière modification par iznobe (Le 13/04/2021, à 11:57)


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

Hors ligne