Bonjour,
Je viens de repasser du noyau 5.10 au noyau 5.15 que j'avais abandonné pour un temps plus long de boot, mais ça me refait la même chose. Au moment où le bureau apparaît (barre de tâches), l'image de fond d'écran ne suit pas et j'ai le disque qui est en lecture à pleine vitesse, on dirait un fsck. Après au moins 30s, j'ai enfin l'image de fond et le disque se calme.
En chronométrant je passe de 30s (5.10) de boot à 1mn20 (5.15) !
En regardant journalctl, j'y voit ça :
juin 17 08:07:27 PC-Pom audit: BPF prog-id=0 op=UNLOAD
juin 17 08:07:27 PC-Pom audit: BPF prog-id=0 op=UNLOAD
juin 17 08:07:27 PC-Pom audit: BPF prog-id=0 op=UNLOAD
juin 17 08:07:27 PC-Pom kernel: audit: type=1334 audit(1655446047.598:75): prog-id=0 op=UNLOAD
juin 17 08:07:27 PC-Pom kernel: audit: type=1334 audit(1655446047.598:76): prog-id=0 op=UNLOAD
juin 17 08:07:27 PC-Pom kernel: audit: type=1334 audit(1655446047.598:77): prog-id=0 op=UNLOAD
juin 17 08:07:57 PC-Pom rtkit-daemon[632]: Supervising 2 threads of 1 processes of 1 users.
juin 17 08:07:57 PC-Pom rtkit-daemon[632]: Supervising 2 threads of 1 processes of 1 users.
juin 17 08:07:58 ...
Qu'est-ce que cet audit que je retrouve beaucoup dans journalctl ?
Est-ce bien là le problème et comment le supprimer ?
Merci de vos suggestions
Denis
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Ce sont les partitions de données supplémentaires (du fstab) qui sont contrôlées sur le HD, pas / ni /home qui sont sur un SSD. Et si je reviens au 5.10, pas de problème, mais dès que je passe au 5.15, j'y ai droit à chaque boot.
Par ailleurs mes partitions sont régulièrement contrôlées (tous les mois) au boot par un paramètre de tune2fs.
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Je réessaierai plus tard : 5.17 ou 5.18 erreur au téléchargement ...
Sinon, lequel passera en LTS ?
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
sudo mhwd-kernel -li
[sudo] Mot de passe de denis :
Currently running: 5.15.46-1-MANJARO (linux515)
The following kernels are installed in your system:
* linux510
* linux515
* linux54
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
sudo journalctl -b0 -p3
juin 17 08:06:43 PC-Pom kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ALIB], AE_NOT_FOUND (20210730/psargs-330)
juin 17 08:06:43 PC-Pom kernel: ACPI Error: Aborting method \_SB.PCI0.VGA.ATC0 due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
juin 17 08:06:43 PC-Pom kernel: ACPI Error: Aborting method \_SB.PCI0.VGA.ATCS due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
juin 17 08:06:43 PC-Pom kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ALIB], AE_NOT_FOUND (20210730/psargs-330)
juin 17 08:06:43 PC-Pom kernel: ACPI Error: Aborting method \_SB.PCI0.VGA.ATC0 due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
juin 17 08:06:43 PC-Pom kernel: ACPI Error: Aborting method \_SB.PCI0.VGA.ATCS due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
juin 17 08:06:59 PC-Pom lightdm[522]: gkr-pam: couldn't unlock the login keyring.
juin 17 08:07:26 PC-Pom pulseaudio[629]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote applicatio>
juin 17 09:19:36 PC-Pom kernel: debugfs: File 'radeon_ring_gfx' in directory '0' already present!
...
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
point concernant les 2 disques
tu as a chaque fois un fsck qui est appliqué je conseille d'ajouter smartctl et de vérifier si tout ce passe bien pour les disques
, il n'est pas conseillé d'avoir les format de partitions mélangés GPT & MBR
Pour la carte mère, on verra ça quand je pourrais accéder au Bios : F2, ESC ou DEL ou ... ne marchent pas !
Gsmartctl ne trouve rien sur le SSD, et 3 secteurs réalloués sur le HDD, mais ça été fait il y a plusieurs années.
Pour le MBR, il est sur le HDD sur lequel je ne boote pas ou plus puisque c'était mon seul disque avant l'arrivée du SSD.
5.17 en cours de chargement
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Même chose avec le 5.17 : 1mn 20 au boot (au lieu des 40s du 5.10) et fsck comme le 5.15
Je repasse au 5.10
Merci pou tes efforts Stéphane
[Edit] et en 40s je boote sur 5.10, sans fsck dans le journalctl !
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
En fait les 40s du boot du 510 se décompose en :
- 15s pour le bios
- 5s d'attente du grub
- 20s de boot de Manjaro (et 1mn avec le 515 ou le 517).
Ce qui me gêne, ce n'est pas tant la durée du boot (j'ai le temps) que ce fsck systématique sur mes 4 partitions de données sur le HDD. Pourquoi est-ce apparu avec le 515 ? Existe-t-il un paramètre pour le supprimer ?
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Denis-pom a écrit : ↑il y a 1 an
Ce qui me gêne, ce n'est pas tant la durée du boot (j'ai le temps) que ce fsck systématique sur mes 4 partitions de données sur le HDD. Pourquoi est-ce apparu avec le 515 ? Existe-t-il un paramètre pour le supprimer ?
Les services systemd-fsck sont lancés à chaque démarrage, mais fsck s'exécute seulement suivant le paramétrage du disque que tu as effectué avec tune2fs. Ce paramétrage est inscrit sur le disque, difficile de voir l'influence d'un changement de noyau sur une vérification fsck.
Tu peux vérifier le paramétrage de chaque partition avec dumpe2fs, par exemple :
sudo dumpe2fs -h /dev/sdc1 | grep -i 'check'
dumpe2fs 1.46.5 (30-Dec-2021)
Last checked: Thu Jun 16 16:04:05 2022
Check interval: 2592000 (1 month)
Next check after: Sat Jul 16 16:04:05 2022
Si vous utilisez le «hook» base de mkinitcpio, vous pouvez forcer la vérification par fsck au démarrage en ajoutant fsck.mode=force aux paramètres du noyau. Cela vérifiera chaque système de fichiers présent sur la machine.
Comme alternative, systemd fournit systemd-fsck@.service(8), qui vérifie tous les systèmes de fichiers configurés, n'ayant pas été vérifiés par l'initramfs. Cependant, vérifier le système de fichier racine de cette façon peut provoquer un ralentissement lors du processus de démarrage étant donné que le système de fichier doit être remonté.
Merci à lemust83 pour la piste !
C'est bien 4 systemd-fsck@.service qui apparaissent dans journalctl pour le 5.15 et qui sont absents pour le 5.10.
Dans mkinitcpio.conf (qui date de 2020 !), j'ai ça pour les Hooks et Modules :
HOOKS=(base udev autodetect modconf block filesystems keyboard keymap fsck)
MODULES=()
J'en ai profité pour commenter 3 lignes du fstab, pour des partitions que j'utilise peu ... Comme cela, quand je devrai passer au 5.17 ou suivant, le fsck ne se fera que sur 1 partition ! Et entre temps, j'aurai gagné bien des montages inutiles .
De tout cela, j'en déduit que le noyau 5.15 a introduit le systemd-fsck@.service (ou a lancé le service au boot), et comme je n'imagine pas bricoler le noyau, je vais conserver mon 5.10 le plus longtemps possible, avec le 5.4 en backup au cas où.
@Smurf
C'est bien le noyau qui est en cause ici, les partitions de données sont paramétrées (tune2fs) pour un fsck mensuel ou trimestriel, au moment du boot. Ça a été fait il y a une semaine, il n'y a pas de raison d'en refaire à chaque boot. Et c'est bien le passage à 5.15 qui active ce fsck à chaque boot.
Je vais continuer d'explorer les pistes fsck, mkinitcpio et systemd-fsck.
Merci à tous pour vos remarques et commentaires
Denis
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Denis-pom a écrit : ↑il y a 1 an
De tout cela, j'en déduit que le noyau 5.15 a introduit le systemd-fsck@.service (ou a lancé le service au boot), et comme je n'imagine pas bricoler le noyau, je vais conserver mon 5.10 le plus longtemps possible, avec le 5.4 en backup au cas où.
@Smurf
C'est bien le noyau qui est en cause ici, les partitions de données sont paramétrées (tune2fs) pour un fsck mensuel ou trimestriel, au moment du boot. Ça a été fait il y a une semaine, il n'y a pas de raison d'en refaire à chaque boot. Et c'est bien le passage à 5.15 qui active ce fsck à chaque boot.
Je vais continuer d'explorer les pistes fsck, mkinitcpio et systemd-fsck.
Le fait que les services systemd-fsck soient lancés au démarrage n'est pas synonyme d'un lancement de fsck.
Les trois premières lignes sont les partitions sur disque mécanique, les trois autres sont sur SSD.
Mon temps de boot :
systemd-analyze
Startup finished in 1.243s (kernel) + 902ms (initrd) + 3.717s (userspace) = 5.863s
graphical.target reached after 3.705s in userspace.
S'il y avait la moindre vérification fsck, même d'une partition SSD, je n'aurais pas des temps aussi courts au démarrage et je l'aurais sans doute vu s'afficher à l'écran.
Bonjour,
Pourtant quand je passe de 20s du 5.10 à 120s du 5.15 et que je vois mon disque tourner à pleine vitesse en lecture pendant la dite minute, j'en déduis qu'il y a bien fsck, d'autant plus que le journalctl me le montre.
CPU : AMD A8-7600, carte mère ASRock FM2A88M-HD+ R3.0 - 8Go RAM
Graph. : AMD Radeon R7
1 SSD 120Go, 1HD 1 To
Manjaro xfce depuis mars 2016, après Ubuntu Voyager 12.04 (et bien d'autres)
Ça dépend de ce que dit journalctl, dans mon cas fsck torche le truc en 2s pour un SSD et trois disques mécaniques, quand il n'a pas à vérifier.
commande :
journalctl -b0 | grep fsck
Ce qui est incompréhensible, c'est que le comportement de fsck n'est normalement pas lié à une version de noyau, mais à la configuration de trois fichiers, /etc/default/grub, /etc/mkinitcpio.conf et /etc/fstab.
attention il a été repris par systemd-fsck,
system-systemd\x2dfsck.slice
et par partition /fstab a verifier
systemd-fsck@dev-disk-by\x2duuid-05923b1e\x2ddbe7\x2d4d73\x2d9440\x2d2c067e02>
systemd-fsck@dev-disk-by\x2duuid-c581e25d\x2d4ea8\x2d4cde\x2d81eb\x2d7a59ed47>
systemd-fsck@dev-disk-by\x2duuid-E05B\x2d8683.service
dans ton cas , il n'est pas normal que cela se produise plus tard , et que cela dure aussi longtemps