# Système de fichier à réparer après chaque reboot (à cause de Plymouth?)

**URL:** <https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713>\
**Category:** Support Debian\
**Created:** [Janvier 12, 2021, 7:52 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713 "2021-01-12T07:52:48Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Janvier 12, 2021, 7:52 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713/1 "2021-01-12T07:52:48Z")

</div>

Hello,

Depuis que j’ai installé Debian 10 sur mon laptop j’ai très souvent eu des soucis après reboot qui heureusement sont assez rares (une fois par mois en gros). Au démarrage ma partition home n’est presque jamais clean (c’est pas systématique non plus) et je dois faire un fsck pour la réparer et continuer le boot.

Je suis maintenant sur Debian 11 (enfin unstable) et depuis peu je suis passé au kernel 5.x. J’ai toujours les mêmes soucis mais j’ai maintenant un message un peu différent incriminant Plymouth. Enfin disons que juste après les messages d’erreurs relatifs au FS je vois un:  
`[OK] Finished "Tell Plymouth to write out runtime data"`

Quelqu’un a déjà rencontré ce genre de souci ?

J’ai un peu peur de perdre des données à force de rebooter…

Sinon de ce que je comprends Plymouth est censé permettre d’avoir un affichage graphique au démarrage mais chez moi ça n’est pas vraiment le cas, j’ai toujours le démarrage classique en mode console jusqu’au démarrage du display manager.

Merci pour votre aide, Vincent.

---

<div class="post-metadata">

**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\
**Post date:** [Janvier 12, 2021, 8:52 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713/2 "2021-01-12T08:52:30Z")

</div>

Salut le fsck sur /home est géré automatiquement pat un service systemd qui s’appuit sur les uuid  
N’y a t-il pas un micmac dans les uuid?

```auto
systemctl status systemd-fsck@dev-disk-by*

```

Attention de ne pas confondre avec le fsct sur / qui est géré au niveau de l’initramfs

```auto
sudo cat /var/run/initramfs/fsck.log

```

Pour lever le doute sur plymouth tu le retires des options de /etc/default/grub. Enlever splash de la ligne

```auto
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

```

puis mettre à jour grub

sudo update-grub

et redemarrer pour voir ce qui se passe sans plymouth

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Janvier 12, 2021, 9:10 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713/3 "2021-01-12T09:10:29Z")

</div>

> [@Vinz](#):
>
> j’ai **très souvent** eu des soucis après reboot qui heureusement sont **assez rares**

C’est un peu contradictoire, non ?

> [@Vinz](#):
>
> ma partition home n’est presque jamais clean (c’est pas systématique non plus) et je dois faire un fsck pour la réparer

Quel type d’erreur est détecté et corrigé par fsck ?

> [@Vinz](#):
>
> j’ai maintenant un message un peu différent incriminant Plymouth. Enfin disons que juste après les messages d’erreurs relatifs au FS je vois un:  
> `[OK] Finished "Tell Plymouth to write out runtime data"`

Ce n’est pas un message d’erreur.

> [@grandtoubab](#):
>
> N’y a t-il pas un micmac dans les uuid?

S’il y avait un problème avec l’UUID défini dans /etc/fstab, le problème se produirait systématiquement.

> [@grandtoubab](#):
>
> Pour lever le doute sur plymouth tu le retires des options de /etc/default/grub. Enlever splash

Il n’y est pas puisque plymouth affiche les lignes d’information «&nbsp;[OK]&nbsp;» au lieu du splash screen. Pour le désactiver complètement, il faut passer le paramètre «&nbsp;nosplash&nbsp;».

---

<div class="post-metadata">

**Author:** ![Vinz](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/87869e/32.png) [@Vinz](https://www.debian-fr.org/u/Vinz)\
**Post date:** [Janvier 12, 2021, 9:46 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713/4 "2021-01-12T21:46:05Z")

</div>

> [@PascalHambourg](#):
>
> > [@Vinz](#):
> >
> > j’ai **très souvent** eu des soucis après reboot qui heureusement sont **assez rares**
> 
> C’est un peu contradictoire, non ?

Arf je voulais dire que je rebootais mon laptop rarement (disons une fois par mois) mais quand je le faisais j’avais souvent le souci (disons 3 fois sur 4).

Mais la chose magique c’est qu’alors que le problème existait depuis près de 2 ans là je n’arrive plus à reproduire malgré plusieurs reboots 🙂

Bon il faut voir qu’entre temps j’ai fait un petit apt-get full-upgrade, c’est pas le premier mais celui là était peut-être le bon. Je suis aussi passé au kernel 5.10 (ça avait déconné au moins un fois avec le 5.9, et plein de fois avec le 4.x).

Merci en tout cas pour votre aide. Intéressant de savoir que le fsck peut ou doit se faire tout seul sur le home. Si ça revient je relancerai le fil..

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Janvier 12, 2021, 9:59 UTC](https://www.debian-fr.org/t/systeme-de-fichier-a-reparer-apres-chaque-reboot-a-cause-de-plymouth/83713/5 "2021-01-12T21:59:36Z")

</div>

> [@Vinz](#):
>
> le fsck peut ou doit se faire tout seul sur le home

Le gestionnaire d’init systemd fait automatiquement un fsck avec l’option -p sur tout système de fichiers défini dans fstab avant de le monter. Mais cela ne peut pas réparer certaines erreurs dont la correction peut avoir des conséquences (perte de données) et nécessite confirmation.
