#101 Le 13/04/2021, à 12:11
- Arbiel
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour à tous.
J'ai été largement interrompu lors de la rédaction de cette présente intervention, aussi peut-elle être décalée par rapport à tout ce qui a été écrit depuis ce matin vers 9h.
Mon installation est tout à fait standard : GPT, UEFI, partition /dev/sda1 nommée «EFI System Partition» en fat32, qui porte les drapeaux esp et boot. Mon disque /dev/sda est un SSD de 500Go. Ma configuration logicielle est moins habituelle : LVM avec deux volumes logiques chiffrés, la racine et mon répertoire personnel.
arbiel@arbiel-NK3S-8-S4:~$ grep " /home/arbiel " /etc/fstab
/dev/mapper/philippe-ophelia /home/arbiel ext4 defaults 0 2
arbiel@arbiel-NK3S-8-S4:~$ /home n'est pas séparé de la racine, seul l'est mon répertoire personnel, hormis d'autres volumes logiques et en particulier /usr.
Je me permets de rappeler que mon attention a été initialement attirée par le message
"Appuyez sur Ctrl+C pour annuler toutes vérifications en cours des systèmes de fichiers."
qui restait affiché pendant toute la durée de l'attente par systemd d'événements qui ne sont jamais arrivés. Cette attente résultait de l'incompatibilté entre systend et mon fichier /etc/crypttab, maintenant contournée.
Le retour de la commande référencée par ce lien met en évidence, par le fait que les dates de vérification des systèmes de fichiers sont antérieures à celles de leur dernière utilisation, que fsck ne vérifie pas les systèmes de fichiers à chaque démarrage, contrairement à ce que laissait croire ce message. Sauf à ce que fsck ne mette exceptionnellement pas à jour ces informations dans un contexte particulier, qui resterait à identifier, mais qui ne peut être celui du traitement du fichier /etc/fstab.
S'agit-il alors d'un contrôle effectué par initrd.img, auquel il manquerait un éventuel module de gestion des informations enregistrées dans les systèmes de fichiers ?
Arbiel
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
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
#102 Le 13/04/2021, à 12:17
- Arbiel
Re : 20.04 : Vérification des disques à chaque démarrage
@iznobe
dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463
c'est ta partition /home :
/dev/sdc1: LABEL="home" UUID="6dd3be64-2092-4e06-817a-ecc5f1463bda" TYPE="ext4" PARTLABEL="home" PARTUUID="382d4183-c7a2-4732-a8b0-13d32e2d21bb"
les «-» étant remplacés par «\x2d»
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
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
#103 Le 13/04/2021, à 13:04
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
je viens d' ajouter l' option " fsck.mode=skip " dans le fichier etc/default/grub et j ' ai refait une analyze de demarrage afin de verifier si il y avait une difference avec precedement :
iznobe@iznobe-PC:~$ systemd-analyze blame
27.584s plymouth-quit-wait.service
8.950s snapd.service
8.656s networkd-dispatcher.service
7.801s udisks2.service
7.750s dev-sdd2.device
5.940s fwupd.service
5.709s NetworkManager-wait-online.service
5.052s bolt.service
5.046s smartmontools.service
5.028s accounts-daemon.service
4.068s nmbd.service
3.967s polkit.service
3.736s NetworkManager.service
3.621s avahi-daemon.service
3.582s dev-loop5.device
3.571s dev-loop0.device
3.459s dev-loop6.device
3.330s switcheroo-control.service
3.327s dev-loop1.device
3.320s thermald.service
3.320s wpa_supplicant.service
3.320s systemd-logind.service
3.291s dev-loop7.device
3.272s postfix@-.service
3.191s dev-loop2.device
3.144s ModemManager.service
3.059s dev-loop8.device
3.041s dev-loop11.device
2.929s dev-loop4.device
2.895s dev-loop12.device
2.726s dev-loop9.device
2.713s dev-loop10.device
2.662s dev-loop3.device
2.537s nfs-server.service
2.501s smbd.service
2.210s grub-common.service
2.026s systemd-journal-flush.service
1.781s apport.service
1.621s networking.service
1.610s colord.service
1.528s gpu-manager.service
1.290s systemd-udevd.service
1.265s gdm.service
1.115s media-nfs_raspibox.mount
1.076s user@1000.service
1.073s rsyslog.service
919ms systemd-resolved.service
839ms apparmor.service
668ms dns-clean.service
582ms e2scrub_reap.service
547ms rpcbind.service
513ms pppd-dns.service
428ms keyboard-setup.service
424ms systemd-modules-load.service
399ms proc-fs-nfsd.mount
395ms upower.service
394ms snap-gnome\x2dsystem\x2dmonitor-57.mount
379ms snap-core-10908.mount
377ms snapd.apparmor.service
364ms snap-gnome\x2dsystem\x2dmonitor-157.mount
346ms snap-gtk\x2dcommon\x2dthemes-818.mount
340ms media-NTFS\x2dcomune.mount
335ms snap-snap\x2dstore-518.mount
328ms systemd-sysusers.service
328ms systemd-udev-trigger.service
316ms packagekit.service
304ms atd.service
304ms snap-gnome\x2d3\x2d34\x2d1804-36.mount
302ms systemd-journald.service
287ms snap-gtk\x2dcommon\x2dthemes-1514.mount
280ms snap-gnome\x2d3\x2d34\x2d1804-66.mount
262ms snap-core-10958.mount
241ms snap-core18-1885.mount
240ms systemd-tmpfiles-setup-dev.service
227ms systemd-user-sessions.service
220ms systemd-tmpfiles-setup.service
211ms media-S4T.mount
208ms nfs-mountd.service
207ms snap-core18-1997.mount
202ms snap-gnome\x2d3\x2d26\x2d1604-100.mount
202ms modprobe@drm.service
197ms snap-gnome\x2d3\x2d26\x2d1604-74.mount
192ms systemd-random-seed.service
180ms systemd-sysctl.service
162ms grub-initrd-fallback.service
161ms systemd-remount-fs.service
159ms run-rpc_pipefs.mount
133ms systemd-timesyncd.service
131ms media-W8T.mount
131ms media-L_M_secours.mount
128ms boot-efi.mount
127ms media-SAUV.mount
126ms ifupdown-pre.service
124ms dev-hugepages.mount
123ms dev-mqueue.mount
122ms media-T3T.mount
120ms sys-kernel-debug.mount
120ms sys-kernel-tracing.mount
117ms kmod-static-nodes.service
108ms media-windows_10.mount
106ms home.mount
103ms snapd.seeded.service
91ms openvpn.service
87ms dev-disk-by\x2duuid-f8a3fadc\x2d7a62\x2d4a73\x2da262\x2df7f50ea7cd83.swap
86ms systemd-update-utmp.service
80ms kerneloops.service
74ms systemd-fsck-root.service
70ms nfs-idmapd.service
67ms plymouth-start.service
67ms media-Sauvegardes.mount
52ms systemd-fsck@dev-disk-by\x2duuid-7132\x2d44A1.service
51ms ufw.service
49ms plymouth-read-write.service
47ms console-setup.service
43ms nfs-config.service
30ms rtkit-daemon.service
15ms user-runtime-dir@1000.service
13ms setvtrgb.service
11ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service
9ms nfs-blkmap.service
4ms alsa-restore.service
4ms systemd-fsck@dev-disk-by\x2dlabel-Sauvegardes.service
3ms media-ramdisk.mount
3ms systemd-update-utmp-runlevel.service
3ms tmp.mount
3ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service
3ms postfix.service
3ms sys-fs-fuse-connections.mount
2ms systemd-fsck@dev-disk-by\x2dlabel-Western_8T.service
2ms systemd-fsck@dev-disk-by\x2dlabel-SAUV.service
2ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service
2ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
1ms snapd.socket
1ms sys-kernel-config.mount
iznobe@iznobe-PC:~$il apparait clairement que le temps des analyses fsck est bien different , ce qui porte a croire qu ' il fait bien des analyses de toutes les partitions a chaque demarrage sans pour autant mettre a jour le compteur ( ou journal ) sans l' option fsck.mode=skip .
lorsque j' a fait l ' analyse a partir de la session live , il ne mettait que quelques secondes pour un disque et environ 30 sec pour la partition de 6.5 Go .
le temps total n ' as quasi pas changé , pourtant on voit bien que fsck skippe non ? les intervalles d' analyse sont quasi instantannés .
j ' ai aussi fait un test en mettant 0 au parametre 6 de toutes les partitions dans le fichier /etc/fstab , dans le resulat de la commande ci dessus les sytemd.fsck disparraissent , mais le temps total ne change pas non plus .
Mais je ne suis pas expert non plus , je vous laisse juger par vous meme .
Dernière modification par iznobe (Le 13/04/2021, à 16:45)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#104 Le 13/04/2021, à 16:31
- erresse
Re : 20.04 : Vérification des disques à chaque démarrage
Je préconiserais donc :
echo "$DESKTOP_SESSION → $XDG_CURRENT_DESKTOP" mate → MATE
Et tu aurais bien raison, car tu vois... ça ne donne pas le même résultat !
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 le problème solutionné, 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
#105 Le 13/04/2021, à 17:43
- nany
Re : 20.04 : Vérification des disques à chaque démarrage
[HS]
Puisque c’est comme ça,
echo "$(awk -F'[ \[]' '/cdrom:/{print $4}' /etc/apt/sources.list || awk '{print $1}' /var/log/installer/media-info) : $DESKTOP_SESSION → $XDG_CURRENT_DESKTOP"
Ubuntu-MATE : xfce → XFCE
[/HS]
En ligne
#106 Le 13/04/2021, à 18:23
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour , d ' apres la doc et l' exemple fourni https://doc.ubuntu-fr.org/fsck#afficher … _partition
j ' ai remarqué qu ' il ne devrait pas y avoir de nombres negatifs dans les counts de montages .
je pense avoir donc resolu le probleme en reconfigurant les valeurs de montages en suivant les indications de la doc :
et en passant pour chaque partition ayant un nombre negatif dans le retour de la commande "showfsck" la commande suivante :
sudo tune2fs -c 150 /dev/nvme0n1p5en adaptant le 150 a votre souhait ( valeur par defaut = 30 ) et bien sur le nom de la partition adequate : nvme0n1p5 .
une fois fait voici ce que ca donne :
iznobe@iznobe-PC:~$ sudo showfsck
[sudo] Mot de passe de iznobe :
150/150 mount(s) until fsck for /dev/nvme0n1p5
16/30 mount(s) until fsck for /dev/sda1
10/15 mount(s) until fsck for /dev/sdb1
13/40 mount(s) until fsck for /dev/sdb2
39/50 mount(s) until fsck for /dev/sdc1
20/25 mount(s) until fsck for /dev/sdc2
48/50 mount(s) until fsck for /dev/sdd1
48/50 mount(s) until fsck for /dev/sdd2
7/35 mount(s) until fsck for /dev/sdd3
iznobe@iznobe-PC:~$et plus de fsck au redemarrage :
iznobe@iznobe-PC:~$ systemd-analyze blame
5.240s NetworkManager-wait-online.service
2.899s udisks2.service
2.881s smartmontools.service
1.472s nfs-server.service
867ms media-NTFS\x2dcomune.mount
571ms systemd-logind.service
451ms systemd-fsck@dev-disk-by\x2dlabel-Ubuntu.service
371ms networkd-dispatcher.service
355ms accounts-daemon.service
338ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service
332ms avahi-daemon.service
331ms NetworkManager.service
330ms polkit.service
327ms ubuntu-system-adjustments.service
315ms switcheroo-control.service
311ms thermald.service
308ms wpa_supplicant.service
307ms lm-sensors.service
298ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service
268ms grub-common.service
262ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service
199ms media-Sauvegardes.mount
173ms dev-nvme0n1p5.device
lines 1-23...skipping...
5.240s NetworkManager-wait-online.service
2.899s udisks2.service
2.881s smartmontools.service
1.472s nfs-server.service
867ms media-NTFS\x2dcomune.mount
571ms systemd-logind.service
451ms systemd-fsck@dev-disk-by\x2dlabel-Ubuntu.service
371ms networkd-dispatcher.service
355ms accounts-daemon.service
338ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service
332ms avahi-daemon.service
331ms NetworkManager.service
330ms polkit.service
327ms ubuntu-system-adjustments.service
315ms switcheroo-control.service
311ms thermald.service
308ms wpa_supplicant.service
307ms lm-sensors.service
298ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service
268ms grub-common.service
262ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service
199ms media-Sauvegardes.mount
173ms dev-nvme0n1p5.device
166ms systemd-fsck@dev-disk-by\x2dlabel-Western_8T.service
161ms mnt-nfs_raspibox.mount
151ms media-Seagate_4T.mount
132ms media-Western_8T.mount
132ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
130ms gpu-manager.service
128ms systemd-resolved.service
125ms user@1000.service
122ms media-L_M_secours.mount
115ms systemd-fsck@dev-disk-by\x2dlabel-Sauvegardes.service
95ms systemd-journal-flush.service
86ms lvm2-monitor.service
85ms home.mount
85ms systemd-fsck@dev-disk-by\x2dlabel-SAUV.service
83ms rsyslog.service
78ms media-SAUV.mount
76ms systemd-timesyncd.service
64ms apparmor.service
62ms upower.service
62ms systemd-udev-trigger.service
49ms media-Ubuntu.mount
47ms dev-disk-by\x2duuid-f8a3fadc\x2d7a62\x2d4a73\x2da262\x2df7f50ea7cd83.swap
47ms smbd.service
40ms dev-hugepages.mount
40ms dev-mqueue.mount
39ms nmbd.service
39ms proc-fs-nfsd.mount
39ms run-rpc_pipefs.mount
38ms sys-kernel-debug.mount
38ms grub-initrd-fallback.service
38ms sys-kernel-tracing.mount
37ms systemd-journald.service
36ms blk-availability.service
35ms systemd-udevd.service
35ms lightdm.service
34ms keyboard-setup.service
30ms kmod-static-nodes.service
30ms ModemManager.service
27ms systemd-modules-load.service
26ms media-Toshiba_3T.mount
25ms systemd-remount-fs.service
23ms e2scrub_reap.service
22ms dns-clean.service
21ms ufw.service
19ms networking.service
17ms systemd-fsck@dev-disk-by\x2duuid-C071\x2d9050.service
17ms ssh.service
16ms plymouth-read-write.service
15ms pppd-dns.service
12ms nfs-mountd.service
11ms nfs-idmapd.service
11ms systemd-tmpfiles-clean.service
11ms media-windows_10.mount
11ms alsa-restore.service
10ms sys-fs-fuse-connections.mount
10ms sys-kernel-config.mount
10ms nfs-blkmap.service
8ms console-setup.service
8ms systemd-random-seed.service
8ms systemd-update-utmp.service
7ms systemd-sysusers.service
7ms systemd-sysctl.service
7ms finalrd.service
7ms systemd-tmpfiles-setup.service
6ms systemd-tmpfiles-setup-dev.service
6ms nfs-config.service
6ms colord.service
6ms hddtemp.service
5ms kerneloops.service
5ms rpcbind.service
4ms user-runtime-dir@1000.service
4ms boot-efi.mount
3ms media-ramdisk.mount
3ms tmp.mount
3ms openvpn.service
3ms systemd-update-utmp-runlevel.service
2ms systemd-user-sessions.service
2ms ifupdown-pre.service
1ms rtkit-daemon.service
977us setvtrgb.service
759us plymouth-quit-wait.service
iznobe@iznobe-PC:~$@nany la derniere commande renvoie un avertissement , d' ailleurs elle me fait un peu peur , juste pour afficher l' environnement graphique 
mais j ' admire ta maitrise de la CLI , bravo 
sous LM :
iznobe@iznobe-PC:~$ echo "$(awk -F'[ \[]' '/cdrom:/{print $4}' /etc/apt/sources.list || awk '{print $1}' /var/log/installer/media-info) : $DESKTOP_SESSION → $XDG_CURRENT_DESKTOP"
awk: avertissement : séquence d'échappement « \[ » traitée comme un simple « [ »
Mint : cinnamon → X-Cinnamon
iznobe@iznobe-PC:~$je repasse sous ubuntu pour verifier que ca fonctionne tjs ...
Dernière modification par iznobe (Le 13/04/2021, à 18:32)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#107 Le 13/04/2021, à 18:38
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Bon et bien le probleme vient bien de ubuntu , il continue a vouloir analyser tout les disques meme avec les compteurs valides , chose que ne fait pas LM :
28.311s plymouth-quit-wait.service
8.908s snapd.service
8.396s networkd-dispatcher.service
8.197s udisks2.service
8.194s dev-sdd2.device
6.463s smartmontools.service
6.388s NetworkManager-wait-online.service
5.991s fwupd.service
5.192s accounts-daemon.service
5.080s bolt.service
4.366s nmbd.service
3.972s dev-loop0.device
3.601s postfix@-.service
3.590s dev-loop7.device
3.551s ModemManager.service
3.548s NetworkManager.service
3.472s dev-loop3.device
3.441s dev-loop5.device
3.354s dev-loop6.device
3.257s dev-loop10.device
3.215s dev-loop12.device
3.132s polkit.service
3.130s dev-loop2.device
3.116s avahi-daemon.service
2.914s switcheroo-control.service
2.913s dev-loop4.device
2.905s systemd-logind.service
2.904s thermald.service
2.903s wpa_supplicant.service
2.872s dev-loop1.device
2.820s dev-loop9.device
2.741s dev-loop11.device
2.670s dev-loop8.device
2.390s systemd-journal-flush.service
2.001s smbd.service
1.993s nfs-server.service
1.805s colord.service
1.642s systemd-udevd.service
1.616s gpu-manager.service
1.318s gdm.service
1.294s grub-common.service
1.289s apport.service
1.186s rsyslog.service
1.125s systemd-resolved.service
1.017s e2scrub_reap.service
858ms user@1000.service
779ms apparmor.service
675ms nfs-mountd.service
604ms networking.service
573ms rpcbind.service
573ms proc-fs-nfsd.mount
520ms packagekit.service
505ms grub-initrd-fallback.service
484ms dns-clean.service
467ms systemd-modules-load.service
463ms snapd.apparmor.service
440ms snap-gtk\x2dcommon\x2dthemes-1514.mount
434ms media-nfs_raspibox.mount
421ms systemd-random-seed.service
409ms systemd-udev-trigger.service
392ms media-NTFS\x2dcomune.mount
389ms snap-gtk\x2dcommon\x2dthemes-818.mount
387ms snap-snap\x2dstore-518.mount
356ms systemd-sysusers.service
346ms keyboard-setup.service
332ms snap-gnome\x2dsystem\x2dmonitor-57.mount
327ms snap-gnome\x2d3\x2d34\x2d1804-66.mount
327ms snap-gnome\x2d3\x2d34\x2d1804-36.mount
324ms systemd-journald.service
321ms systemd-tmpfiles-setup-dev.service
313ms snap-core-10908.mount
302ms snap-gnome\x2dsystem\x2dmonitor-157.mount
302ms snap-gnome\x2d3\x2d26\x2d1604-100.mount
299ms snap-gnome\x2d3\x2d26\x2d1604-74.mount
297ms systemd-tmpfiles-setup.service
288ms media-S4T.mount
267ms systemd-sysctl.service
244ms upower.service
233ms modprobe@drm.service
230ms systemd-hostnamed.service
226ms atd.service
219ms snap-core-10958.mount
205ms run-rpc_pipefs.mount
197ms media-T3T.mount
193ms systemd-timesyncd.service
189ms snap-core18-1885.mount
181ms systemd-remount-fs.service
180ms snap-core18-1997.mount
169ms pppd-dns.service
161ms nfs-idmapd.service
153ms kerneloops.service
150ms home.mount
143ms ifupdown-pre.service
142ms openvpn.service
141ms media-windows_10.mount
141ms media-windows_10.mount
141ms snapd.seeded.service
139ms media-L_M_secours.mount
123ms media-W8T.mount
106ms media-Sauvegardes.mount
99ms ufw.service
85ms geoclue.service
84ms nfs-blkmap.service
84ms dev-disk-by\x2duuid-f8a3fadc\x2d7a62\x2d4a73\x2da262\x2df7f50ea7cd83.swap
83ms dev-hugepages.mount
83ms rtkit-daemon.service
82ms dev-mqueue.mount
80ms sys-kernel-debug.mount
79ms nfs-config.service
79ms sys-kernel-tracing.mount
76ms kmod-static-nodes.service
75ms systemd-localed.service
70ms media-SAUV.mount
67ms plymouth-start.service
54ms systemd-user-sessions.service
41ms systemd-update-utmp.service
40ms setvtrgb.service
36ms systemd-fsck-root.service
33ms console-setup.service
31ms plymouth-read-write.service
25ms boot-efi.mount
13ms user-runtime-dir@1000.service
11ms media-ramdisk.mount
9ms tmp.mount
4ms systemd-update-utmp-runlevel.service
4ms systemd-fsck@dev-disk-by\x2duuid-7132\x2d44A1.service
3ms alsa-restore.service
3ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service
3ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service
2ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
2ms systemd-fsck@dev-disk-by\x2dlabel-SAUV.service
2ms systemd-fsck@dev-disk-by\x2dlabel-Sauvegardes.service
2ms snapd.socket
2ms sys-fs-fuse-connections.mount
2ms systemd-fsck@dev-disk-by\x2dlabel-Western_8T.service
2ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service
2ms sys-kernel-config.mount
680us postfix.serviceiznobe@iznobe-PC:~$ sudo showfsck
[sudo] Mot de passe de iznobe :
15/30 mount(s) until fsck for /dev/sda1
9/15 mount(s) until fsck for /dev/sdb1
12/40 mount(s) until fsck for /dev/sdb2
38/50 mount(s) until fsck for /dev/sdc1
19/25 mount(s) until fsck for /dev/sdc2
47/50 mount(s) until fsck for /dev/sdd1
47/50 mount(s) until fsck for /dev/sdd2
6/35 mount(s) until fsck for /dev/sdd3
iznobe@iznobe-PC:~$j ' ai laissé l' option " fsck.mode=skip " activé dans etc/defaut/grub .
Dernière modification par iznobe (Le 13/04/2021, à 18:40)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#108 Le 13/04/2021, à 20:04
- Coeur Noir
Re : 20.04 : Vérification des disques à chaque démarrage
Ta LM et ton Ubuntu ont le même noyau ?
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#109 Le 13/04/2021, à 20:11
- Arbiel
Re : 20.04 : Vérification des disques à chaque démarrage
Bonsoir à tous
En fin d'après-midi, j'ai redémarré trois fois mon PC, une première fois avec fsck.mode=skip, puis avec fsck.mode=force et enfin sans fsck.mode comme le montre cet extrait du journal de systemd
arbiel@arbiel-NK3S-8-S4:~$ grep -E "avril 13 1.*Kernel command line.*" /tmp/journal
avril 13 18:02:59 arbiel-NK3S-8-S4 kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=skip
avril 13 18:03:05 arbiel-NK3S-8-S4 /usr/lib/gdm3/gdm-x-session[1549]: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=skip
avril 13 18:09:08 arbiel-NK3S-8-S4 kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=force
avril 13 18:09:18 arbiel-NK3S-8-S4 /usr/lib/gdm3/gdm-x-session[1572]: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=force
avril 13 19:06:02 arbiel-NK3S-8-S4 kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7
avril 13 19:06:08 arbiel-NK3S-8-S4 /usr/lib/gdm3/gdm-x-session[1593]: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7
arbiel@arbiel-NK3S-8-S4:~$ Voilà ce que j'obtiens pour ce qui concerne fsck:
arbiel@arbiel-NK3S-8-S4:~$ grep "fsck" /home/arbiel/Bureau/ubuntu_forum/journal_04_13.sans_mode.txt
avril 13 19:06:02 arbiel-NK3S-8-S4 systemd[1]: Created slice system-systemd\x2dfsck.slice.
avril 13 19:06:02 arbiel-NK3S-8-S4 systemd[1]: Listening on fsck to fsckd communication Socket.
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1153]: /dev/mapper/philippe-secours : propre, 171953/917504 fichiers, 2395087/3670016 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1203]: philippe-melopoi : propre, 450/983040 fichiers, 1502400/3932160 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1216]: philippe-biblioi : propre, 758/262144 fichiers, 278568/1048576 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1214]: /dev/mapper/philippe-xavier : propre, 316/65536 fichiers, 79801/262144 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1215]: philippe-eidonta : propre, 90/2621440 fichiers, 946662/10485760 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1218]: philippe-phortos : propre, 8395/655360 fichiers, 1419703/2621440 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 systemd-fsck[1208]: philippe-ophelia : propre, 65198/983040 fichiers, 2572497/3928064 blocs
avril 13 19:06:06 arbiel-NK3S-8-S4 kernel: EXT4-fs (dm-6): warning: mounting unchecked fs, running e2fsck is recommended
avril 13 19:06:11 arbiel-NK3S-8-S4 kernel: EXT4-fs (mmcblk0p2): warning: mounting unchecked fs, running e2fsck is recommended
avril 13 19:06:11 arbiel-NK3S-8-S4 kernel: FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
arbiel@arbiel-NK3S-8-S4:~$ arbiel@arbiel-NK3S-8-S4:~$ grep "avril 13 18:08:4" '/home/arbiel/Bureau/ubuntu_forum/journal_04_13.mode=force.txt' | g fsck
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dusr.service: Succeeded.
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dsecours.service: Succeeded.
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dbiblioi.service: Succeeded.
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dmelopoi.service: Succeeded.
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dxavier.service: Succeeded.
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2deidonta.service: Succeeded.
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dphortos.service: Succeeded.
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dophelia.service: Succeeded.
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: Removed slice system-systemd\x2dfsck.slice.
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck-root.service: Succeeded.
arbiel@arbiel-NK3S-8-S4:~$ arbiel@arbiel-NK3S-8-S4:~$ grep "avril 13 18:" '/home/arbiel/Bureau/ubuntu_forum/journal_04_13.mode=skip.txt' | g fsck
avril 13 18:02:30 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dbiblioi.service: Succeeded.
avril 13 18:02:30 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2deidonta.service: Succeeded.
avril 13 18:02:30 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dmelopoi.service: Succeeded.
avril 13 18:02:30 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dophelia.service: Succeeded.
avril 13 18:02:31 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dphortos.service: Succeeded.
avril 13 18:02:31 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dsecours.service: Succeeded.
avril 13 18:02:31 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dxavier.service: Succeeded.
avril 13 18:02:31 arbiel-NK3S-8-S4 systemd[1]: Removed slice system-systemd\x2dfsck.slice.
avril 13 18:02:59 arbiel-NK3S-8-S4 kernel: Command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=skip
avril 13 18:02:59 arbiel-NK3S-8-S4 kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=skip
avril 13 18:02:59 arbiel-NK3S-8-S4 systemd[1]: Created slice system-systemd\x2dfsck.slice.
avril 13 18:02:59 arbiel-NK3S-8-S4 systemd[1]: Listening on fsck to fsckd communication Socket.
avril 13 18:03:04 arbiel-NK3S-8-S4 kernel: EXT4-fs (dm-6): warning: mounting unchecked fs, running e2fsck is recommended
avril 13 18:03:05 arbiel-NK3S-8-S4 /usr/lib/gdm3/gdm-x-session[1549]: Kernel command line: BOOT_IMAGE=/vmlinuz-5.8.0-48-generic root=UUID=5ab1950c-cd24-42d3-a4a6-256985877370 ro quiet splash vt.handoff=7 fsck.mode=skip
avril 13 18:03:08 arbiel-NK3S-8-S4 kernel: EXT4-fs (mmcblk0p2): warning: mounting unchecked fs, running e2fsck is recommended
avril 13 18:03:08 arbiel-NK3S-8-S4 kernel: FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
arbiel@arbiel-NK3S-8-S4:~$ Comprenne qui pourra.
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
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
#110 Le 13/04/2021, à 20:52
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Ta LM et ton Ubuntu ont le même noyau ?
oui , ils sont tous les 2 avec le noyau 5.10.29 il me semble , j' ai choisi celui-ci car c ' est le seul en version LTS qui prend nativement le pilote de ma carte reseau via le module r8169 .
d' ailleur a ce propos qui n' a rien a voir avec le probleme actuel , je posterai une demande pour trouver moyen d' arreter de recevoir les mises a jour pour les 2 series de noyaux " par defaut " d ' ubuntu .
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:~$ @arbiel , tu maitrises dis donc 
, le " | g fsck " c ' est pour l' alias ? ( grep "avril 13 18 :" ) je suis debutant desolé .
c ' est sur un pi ?
Par contre ca ne reflete pas grand choses si ce n' est qu ' avec les 3 modes ( si j' ai bien compris , ) il tente tjs d ' analyser les partitions , sauf que dans 2 cas il ne detaille pas le retour autrement q u' en disant succés ?
Par contre on voit qu il a une dent contre ta partition en FAT mmcblk0p1 , sauf dans le mode force .
peut etre il y aurait une erreur pendant l' arret lors du demontage de la partition de boot en fat si je me trompe pas , pure supposition 
.
Dernière modification par iznobe (Le 13/04/2021, à 21:15)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#111 Le 13/04/2021, à 23:19
- Arbiel
Re : 20.04 : Vérification des disques à chaque démarrage
Bonsoir
En préambule : ne parlons pas du premier bloc de code que j'ai affiché, dont le but était de permettre à quiconque le souhaite de vérifier que je ne me trompe pas sur mon utilisation du paramètre fsck.mode. Ce qui suit concerne les trois blocs de code qui sont les extraits du journal de systemd.
Par ailleurs les partitions mmcblk0p. sont deux partitions sur une carte SD, qui peuvent être ignorées.
Dans le premier bloc, fsck.mode n'a pas été utilisé. Il me semble que systemd lance une première campagne de vérification
avril 13 19:06:02 arbiel-NK3S-8-S4 systemd[1]: Created slice system-systemd\x2dfsck.slice.
avril 13 19:06:02 arbiel-NK3S-8-S4 systemd[1]: Listening on fsck to fsckd communication Socket.qui se bornerait à fournir les informations générales enregistrées dans les systèmes de fichiers sans vraiment les vérifier, c'est du moins ce que j'intreprète de la ligne
avril 13 19:06:06 arbiel-NK3S-8-S4 kernel: EXT4-fs (dm-6): warning: mounting unchecked fs, running e2fsck is recommendedLa partition dm-6 est ma partition racine que systemd indique ne pas avoir contrôlée. Pourquoi le même avertissement n'apparaît-il pas pour les autres systèmes de fichiers ?
Dans le deuxième bloc, j'ai utilisé fsck.mode=force. On ne voit pas apparaître le début de la campagne de vérification (mauvais fitre de ma part ?), mais on en voit les résultats fructueux
avril 13 18:08:41 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck@dev-mapper-philippe\x2dusr.service: Succeeded.et la fermeture
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: Removed slice system-systemd\x2dfsck.slice.suivi par la vérification fructueuse de la partition racine
avril 13 18:08:43 arbiel-NK3S-8-S4 systemd[1]: systemd-fsck-root.service: Succeeded.Dans le troisième bloc, j'ai utilisé le paramètre fsck.mode=skip. On constate les mêmes résultats, absolument surprenants, que dans le cas précédent pour les partitions autres que la racine et que /usr. Après la fin de cette campagne, systemd en lance une seconde, pour la racine et pour /usr (?) qui n'aboutit pas.
Pour ce qui concerne les dates de vérification et d'utilisation des partitions, j'ai redémarré mon PC en début de soirée. On constate que les dernières vérifications enregistrées dans les systèmes de fichiers sont celles de mon démarrage avec fsck.mode=force, à 18:08-18:09
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: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
/dev/philippe/xavier
Last mounted on: /boot
Last mount time: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
/dev/philippe/usr
Last mounted on: /usr
Last mount time: Tue Apr 13 21:56:26 2021
Last write time: Tue Apr 13 21:56:26 2021
Last checked: Tue Apr 13 18:09:07 2021
Next check after: Thu May 13 18:09:07 2021
/dev/philippe/gumnon
Last mounted on: /home/arbiel/Documents/gumnon
Last mount time: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 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: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 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: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
/dev/philippe/phortos
Last mounted on: /home/arbiel/Téléchargements
Last mount time: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
/dev/philippe/biblioi
Last mounted on: /home/arbiel/Bureau/Biblioi
Last mount time: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
/dev/philippe/melopoi
Last mounted on: /home/arbiel/Bureau/Musique
Last mount time: Tue Apr 13 21:56:31 2021
Last write time: Tue Apr 13 21:56:31 2021
Last checked: Tue Apr 13 18:09:12 2021
Next check after: Thu May 13 18:09:12 2021
arbiel@arbiel-NK3S-8-S4:~$ sauf pour les deux systèmes de fichiers pour lesquels j'ai laissé le 6e paramètre de fstab à 0.
D'où ma complète incompréhension de ces résultats, qui me pousse à abandonner et à me focaliser sur mon clavier qui se comporte de manière aberrante.
Arbiel
Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04, GNOME 3.36.8
24.04 en cours de tests
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
#112 Le 14/04/2021, à 00:08
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Pour info ,
je viens de creer une nouvelle partition sur mon disque nvme , j ' y ai installé ubuntu 18.04.5 LTS , remis le noyau 5.10.29 et passé les commandes suivantes :
iznobe@iznobe-PC:~$ sudo showfsck
***************************
* -6 * /-1 mount(s) until fsck for /dev/nvme0n1p6
***************************
7/15 mount(s) until fsck for /dev/sdb1
33/50 mount(s) until fsck for /dev/sdc1
iznobe@iznobe-PC:~$ iznobe@iznobe-PC:~$ systemd-analyze blame
20.737s plymouth-quit-wait.service
5.020s bolt.service
1.114s udisks2.service
504ms systemd-logind.service
347ms fwupd.service
294ms snap-gtk\x2dcommon\x2dthemes-818.mount
292ms snap-gnome\x2d3\x2d26\x2d1604-74.mount
277ms snapd.service
254ms snap-gnome\x2dsystem\x2dmonitor-57.mount
254ms snap-core-6350.mount
207ms snap-gnome\x2dcalculator-260.mount
207ms snap-gnome\x2dcharacters-139.mount
189ms dev-nvme0n1p6.device
176ms dev-loop1.device
175ms dev-loop2.device
173ms dev-loop0.device
172ms snap-gnome\x2dlogs-45.mount
145ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
88ms dev-loop3.device
88ms dev-loop4.device
83ms networkd-dispatcher.service
63ms systemd-journal-flush.service
60ms systemd-udev-trigger.service
58ms user@1000.service
49ms NetworkManager.service
44ms apparmor.service
42ms home.mount
39ms dev-loop5.device
38ms dev-disk-by\x2duuid-f8a3fadc\x2d7a62\x2d4a73\x2da262\x2df7f50ea7cd83.swap
37ms ModemManager.service
35ms networking.service
35ms grub-common.service
31ms speech-dispatcher.service
30ms avahi-daemon.service
28ms accounts-daemon.service
27ms keyboard-setup.service
26ms rsyslog.service
26ms upower.service
26ms gpu-manager.service
22ms systemd-resolved.service
22ms plymouth-start.service
22ms systemd-timesyncd.service
21ms boot-efi.mount
21ms systemd-journald.service
21ms systemd-modules-load.service
19ms packagekit.service
19ms systemd-udevd.service
17ms wpa_supplicant.service
16ms systemd-fsck@dev-disk-by\x2duuid-C071\x2d9050.service
15ms NetworkManager-wait-online.service
15ms apport.service
15ms colord.service
15ms thermald.service
11ms gdm.service
10ms plymouth-read-write.service
9ms alsa-restore.service
8ms snapd.seeded.service
7ms snapd.apparmor.service
6ms ureadahead-stop.service
6ms polkit.service
6ms systemd-tmpfiles-setup-dev.service
6ms dns-clean.service
6ms systemd-tmpfiles-setup.service
4ms systemd-tmpfiles-clean.service
4ms systemd-update-utmp-runlevel.service
4ms systemd-sysctl.service
3ms kerneloops.service
3ms pppd-dns.service
3ms dev-hugepages.mount
3ms systemd-update-utmp.service
2ms ufw.service
2ms systemd-remount-fs.service
2ms sys-kernel-debug.mount
2ms systemd-random-seed.service
1ms console-setup.service
1ms kmod-static-nodes.service
1ms rtkit-daemon.service
1ms dev-mqueue.mount
1ms systemd-user-sessions.service
1ms setvtrgb.service
1ms sys-fs-fuse-connections.mount
824us sys-kernel-config.mount
601us snapd.socket
iznobe@iznobe-PC:~$ sudo showfsckle fstab n ' est pas identique donc je pense qu il n ' a pas analysé les partitions a cause de ca , mais le retour de la 1er commande avec les chiffres negatifs me fait penser que le bug etait deja present dans la 18.04 du moins sur cette partie là .
Pour la suite je ferais ca demain .
Dernière modification par iznobe (Le 14/04/2021, à 00:12)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#113 Le 14/04/2021, à 08:55
- malbo
Re : 20.04 : Vérification des disques à chaque démarrage
@cqfd93 : je viens de tomber sur ce rapport de bug #1905166 qui me fait penser que tu as peut-être un souci à l'extinction de l'ordi comme dans ce bug.
Peux-tu donner le retour de la commande suivante :
journalctl | grep systemd-shutdownHors ligne
#114 Le 14/04/2021, à 09:14
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour ,
@malbo voici pour mon cas sur la nouvelle install ssd :
iznobe@iznobe-PC:~$ journalctl | grep systemd-shutdown
avril 13 23:41:01 iznobe-PC systemd-shutdown[1]: Syncing filesystems and block devices.
avril 13 23:41:01 iznobe-PC systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 14 00:22:30 iznobe-PC systemd-shutdown[1]: Syncing filesystems and block devices.
avril 14 00:22:30 iznobe-PC systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 14 09:06:05 iznobe-PC systemd-shutdown[1]: Syncing filesystems and block devices.
avril 14 09:06:05 iznobe-PC systemd-shutdown[1]: Sending SIGTERM to remaining processes...
iznobe@iznobe-PC:~$vu que le bug n ' a pas l ' air d ' etre present , je referais un test avec l ' install qui a le probleme .
Pour la suite du post d ' hier , j ' ai donc modifié mon fstab et créé les points de montages comme suit :
iznobe@iznobe-PC:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p6 during installation
UUID=06bc0f51-50e8-4ed4-8090-903acdb7df3f / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p3 during installation
UUID=C071-9050 /boot/efi vfat umask=0077 0 1
# /home was on /dev/sdc1 during installation
UUID=6dd3be64-2092-4e06-817a-ecc5f1463bda /home ext4 defaults 0 2
# swap was on /dev/sdc3 during installation
UUID=f8a3fadc-7a62-4a73-a262-f7f50ea7cd83 none swap sw 0 0
# MONTAGES PARTITIONS :
# partition de données partagées windows 10
/dev/disk/by-label/comune /media/NTFS-comune ntfs-3g defaults,locale=fr_FR.UTF-8,uid=1000,gid=1000,windows_names 0 0
#/dev/disk/by-label/windows_10 /media/windows_10 ntfs-3g defaults 0 0
/dev/disk/by-label/L_M_secours /media/L_M_secours ext4 defaults 0 2
/dev/disk/by-label/Sauvegardes /media/Sauvegardes ext4 defaults 0 2
/dev/disk/by-label/SAUV /media/SAUV ext4 defaults 0 2
/dev/disk/by-label/Seagate_4T /media/S4T ext4 defaults 0 2
/dev/disk/by-label/Toshiba_3T /media/T3T ext4 defaults 0 2
/dev/disk/by-label/Western_8T /media/W8T ext4 defaults 0 2
iznobe@iznobe-PC:~$redemarrer l' ordi et fait :
iznobe@iznobe-PC:~$ sudo showfsck
[sudo] Mot de passe de iznobe :
***************************
* -8 * /-1 mount(s) until fsck for /dev/nvme0n1p6
***************************
13/30 mount(s) until fsck for /dev/sda1
***************************
* 5 * /15 mount(s) until fsck for /dev/sdb1
***************************
10/40 mount(s) until fsck for /dev/sdb2
31/50 mount(s) until fsck for /dev/sdc1
17/25 mount(s) until fsck for /dev/sdc2
45/50 mount(s) until fsck for /dev/sdd1
***************************
* 4 * /35 mount(s) until fsck for /dev/sdd3
***************************
iznobe@iznobe-PC:~$ les compteurs apres modification anterieurement sont tous bons , dans le sens ou il ne devrait pas y avoir de fsck au demarrage sauf pour la partition " / " nouvellement crée pour la nouvelle distrib .
puis :
iznobe@iznobe-PC:~$ systemd-analyze blame | grep systemd-fsck
361ms systemd-fsck@dev-disk-by\x2dlabel-Seagate_4T.service
270ms systemd-fsck@dev-disk-by\x2duuid-6dd3be64\x2d2092\x2d4e06\x2d817a\x2decc5f1463bda.service
181ms systemd-fsck@dev-disk-by\x2dlabel-Sauvegardes.service
169ms systemd-fsck@dev-disk-by\x2dlabel-Western_8T.service
151ms systemd-fsck@dev-disk-by\x2dlabel-Toshiba_3T.service
151ms systemd-fsck@dev-disk-by\x2dlabel-L_M_secours.service
62ms systemd-fsck@dev-disk-by\x2dlabel-SAUV.service
14ms systemd-fsck@dev-disk-by\x2duuid-C071\x2d9050.service
iznobe@iznobe-PC:~$Alors je ne sais pas si il skipp ou si il fait reellement la verif , mais niveau timing c ' est tres rapide !
je n' obtiens pas le message de verification avec ctrl + c .
et je n' ai pas non plus la pause sur le message scan for btrfs file system .
rien d' autre n ' a été modifié sur la nouvelle distrib a part les mises a jours .
je vais regarder en detail le lien que donne @malbo .
Dernière modification par iznobe (Le 14/04/2021, à 09:34)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#115 Le 14/04/2021, à 09:38
- cqfd93
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour,
@cqfd93 : je viens de tomber sur ce rapport de bug #1905166 qui me fait penser que tu as peut-être un souci à l'extinction de l'ordi comme dans ce bug.
Peux-tu donner le retour de la commande suivante :journalctl | grep systemd-shutdown
Non, pas de problème de ce genre :
moi@moi-lenovo:~$ journalctl | grep systemd-shutdown
avril 07 15:57:40 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 07 15:57:40 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 07 16:15:43 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 07 16:15:44 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 07 16:41:32 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 07 17:06:41 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 07 17:06:42 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 07 19:58:00 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 07 19:58:01 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 08 10:58:03 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 08 10:58:03 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 09 10:40:08 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 09 10:40:09 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 09 16:05:31 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 09 16:05:31 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 09 16:33:31 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 09 16:33:31 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 09 17:27:35 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 09 17:27:36 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 10 14:54:24 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 10 14:54:25 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 11 09:46:20 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 11 09:46:21 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
avril 13 10:25:20 moi-lenovo systemd-shutdown[1]: Syncing filesystems and block devices.
avril 13 10:25:21 moi-lenovo systemd-shutdown[1]: Sending SIGTERM to remaining processes...
moi@moi-lenovo:~$ − cqfd93 −
Hors ligne
#116 Le 14/04/2021, à 11:04
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Re , pour moi le probleme serait plutot ca , sauf qu ' on ne voit pas le message a part sur LM :
https://bugs.launchpad.net/ubuntu/+sour … ug/1460447 et engendrerai le fsck au boot juste apres .
Comment fait on svp deja sur ubuntu pour afficher les messages de boot au demarrage a la place de l' ecran violet ? une option a ajouter dans /etc/default/grub me semble t il , mais me rappelle plus laquelle .
Dernière modification par iznobe (Le 14/04/2021, à 11:05)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#117 Le 14/04/2021, à 11:23
- cqfd93
Re : 20.04 : Vérification des disques à chaque démarrage
Je pense qu'il faut commenter la ligne
GRUB_TIMEOUT_STYLE=hidden− cqfd93 −
Hors ligne
#118 Le 14/04/2021, à 12:10
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
merci cqfd93 , j' ai commenté la ligne et enlever " quiet " .
suivi de
sudo update-grubet là il affiche le nombre de disque qu ' il scanne , mais sur le nvme faut etre attentif , sur les disques mecaniques classiques le fsck est visible mais tres rapide .
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#119 Le 15/04/2021, à 11:32
- iznobe
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour , apres plusieurs essais un peu partout , en mettant des compteurs de montage tout frais avec tune2fs comme decrit dans un de mes message precedent , le probleme se resout pour les partitions ayant un chiffre a 2 pour 6eme parametres dans /etc/fstab .
le retour dans le " systemd-analyse | grep fsck " a mon avis ( supposition ), montre que fsck a lu les parametres de compteurs de chaque partition du fstab , mais n ' effectue pas la verification si il y en a pas besoin .
le probleme persiste par contre avec les partitions / , /home , /boot , EFI , en gros toutes celles avec le parametres n° 6 du fstab a 1 .
ca ne se produit , a priori , que sur la version 20.04 ( j ' ai pas testé hirsute ) .
j ' ai remarqué aussi un autre phenomene assez curieux au demarrage apres avoir enlevé le screen ubuntu .
Au boot de l ' ordi , il reste bloqué plusieurs secondes sur Running /scripts/local/premount .
la solution est de passé ces 2 commandes pour supprimer ce soucis , si vous n' avez pas de partition au format " btrfs " bien sur :
sudo apt-get purge btrfs-toolssudo update-initramfs -ukallce qui permet de gagner environ 15 sec au demarrage si vous etes victimes de ce bug
Du coup je presume que si on savait ou etaient gerées les partitions avec le parametre 6 du fstab a 1 , on pourrait mettre de l' ordre , vu que si je me trompe pas , remettre le compteur de montage a une valeur positive corrige le probleme .
Dernière modification par iznobe (Le 15/04/2021, à 11:37)
retour COMPLET et utilisable de commande | script montage partitions
MSI Z490A-pro , i7 10700 , 32 GB RAM .
Hors ligne
#120 Le 15/04/2021, à 11:54
- ylag
Re : 20.04 : Vérification des disques à chaque démarrage
Bonjour,
j ' ai remarqué aussi un autre phenomene assez curieux au demarrage apres avoir enlevé le screen ubuntu .
Au boot de l ' ordi , il reste bloqué plusieurs secondes sur Running /scripts/local/premount .
J'ai remarqué le même comportement qui se produisait de façon aléatoire avec certaines versions (pas toutes...) du noyau 4.4.xx sur Ubuntu 16.04.
Pas vu de tel comportement à date sur la 18.04 avec les noyaux de version 4.15.xx, ni sur une Debian Buster (stable) avec noyau en version 4.19.xx.
Pas encore de 20.04 installée sur mon système.
Aucun paquet lié à btrfs n'est installé chez-moi, incluant btrfs-tools.
A+
Dernière modification par ylag (Le 15/04/2021, à 11:56)
Hors ligne