#76 Le 12/04/2021, à 16: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, à 17:08
- ylag
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour,
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, à 17: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, à 17: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ébuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#80 Le 12/04/2021, à 18: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, à 18: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.
En ligne
#81 Le 12/04/2021, à 18:32
- cqfd93
Re : 20.04 : Vérification des disques à chaque démarrage
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 −
En ligne
#82 Le 12/04/2021, à 18: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 .
En ligne
#83 Le 12/04/2021, à 18: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.
En ligne
#84 Le 12/04/2021, à 18:52
- nany
Re : 20.04 : Vérification des disques à chaque démarrage
echo "${XDG_CURRENT_DESKTOP}"
echo "${XDG_CURRENT_DESKTOP}"
printenv XDG_CURRENT_DESKTOP
Hors ligne
#85 Le 12/04/2021, à 19: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, à 19:09)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#86 Le 12/04/2021, à 19: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, à 19: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, à 19: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, à 19:30)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#88 Le 12/04/2021, à 22: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, à 22:28)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#89 Le 12/04/2021, à 23: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, à 23:38)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#90 Le 12/04/2021, à 23: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, à 23:49)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#91 Le 13/04/2021, à 04: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 ?
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 »
_________________________
à 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, à 04:56)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#92 Le 13/04/2021, à 08: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à
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, à 09:20)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#93 Le 13/04/2021, à 09:14
- cqfd93
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour,
@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 −
En ligne
#94 Le 13/04/2021, à 09: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, à 09:30)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#95 Le 13/04/2021, à 09: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, à 09:44)
Xubuntu 22.04 - Mes projets sur Github
Hors ligne
#96 Le 13/04/2021, à 09: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
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, à 10:00)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#97 Le 13/04/2021, à 10:23
- cqfd93
Re : 20.04 : Vérification des disques à chaque démarrage
Non, je n'ai pas de ssd.
− cqfd93 −
En ligne
#98 Le 13/04/2021, à 10: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, à 10:39)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#99 Le 13/04/2021, à 11:42
- nany
Re : 20.04 : Vérification des disques à chaque démarrage
[HS]
@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.
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,
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, à 11: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, à 12:57)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne