# Problème FStab depuis mise à jour vers Buster et noyau 4.19.37-5

**URL:** <https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791>\
**Category:** Support Debian\
**Tags:** kernel, boot\
**Created:** [Juillet 31, 2019, 9:16 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791 "2019-07-31T09:16:47Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sioban](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/53a042/32.png) [@sioban](https://www.debian-fr.org/u/sioban)\
**Post date:** [Juillet 31, 2019, 9:16 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/1 "2019-07-31T09:16:47Z")

</div>

Bonjour,

J’ai mis à jour mon serveur depuis Jessie vers Buster récemment.

J’ai eu quelques soucis avec le montage de mes partitions liés au noyau 4.19. Si je boot en 4.9, je n’ai aucun soucis.

Voici mon Fstab tel qu’il était avant la mise à jour :

```nohighlight
#/etc/fstab: static file system information.

/dev/md1 / xfs defaults,nobarrier 0 1
/dev/md0 /boot ext2 defaults 0 2
/dev/md9 /home xfs defaults,nobarrier 0 2
/dev/md3 /tmp xfs defaults,nobarrier 0 2
/dev/md4 /usr xfs defaults,nobarrier 0 2
/dev/md5 /var xfs defaults,nobarrier 0 2
/dev/md8 /var/lib xfs defaults,nobarrier 0 2
/dev/md6 /var/log xfs defaults,nobarrier 0 2
/dev/md7 /var/spool xfs defaults,nobarrier 0 2
/dev/md2 none swap sw 0 0
/dev/sda1 /home/archives/downloads ext4 rw,nosuid,nodev,auto,async,noatime,discard,nouser,defaults 0 2

#NAS
//10.10.12.201/z-archives /mnt/z-archives cifs rw,noperm,nosuid,nodev,auto,file_mode=0777,dir_mode=0777,iocharset=utf8,credentials=/root/.nascredentials,uid=0,gid=124 0 0

```

J’ai du le modifier un peu pour arriver à démarrer :

1. nobarrier n’est plus supporté, j’ai du les enlever
2. j’ai eu à spécifier la version de SMB pour le NAS, j’ai mis vers=1.0 car 2.0 me fait perdre les symlinks et mfsymlinks est mal supporté par mon média player

Cependant je n’arrive toujours pas à monter `/dev/sda1`, le boot passe en mode emergency et me demande mon mot de passe que je rentre pour voir ce qu’il se passe. Malheureusement il ne me donne pas de shell, je ne peux donc pas taper les commandes systemctl ou journalctl pour savoir ce qu’il se passe. Si je reboot en 4.9, je n’ai pas de trace dans les logs.

Voici la ligne concernant le montage telle qu’elle est aujourd’hui et qui bloque toujours (j’ai essayé de la réduire au strict minimal) :

```nohighlight
/dev/sda1 /home/archives/downloads ext4 rw,nosuid,nodev,auto,nouser,defaults 0 2

```

La photo de mon boot à ce moment : [https://framapic.org/f8nT4un4hBkj/oPoiTtX2qul3.jpg](https://framapic.org/f8nT4un4hBkj/oPoiTtX2qul3.jpg)

Avez vous une piste ?

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Juillet 31, 2019, 11:31 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/2 "2019-07-31T11:31:01Z")

</div>

> [@sioban](#):
>
> /dev/sda1 /home/archives/downloads ext4 rw,nosuid,nodev,auto,nouser,defaults 0 2

Dans un premier temps, il me semble sage de réduire les options à `defaults,noauto`  
De cette manière, s’il y a un problème avec ce montage, votre système démarrera quand même et vous serez à l’aise pour diagnostiquer et réparer.  
D’abord remplacer `/dev/sda1`par un UUID)xxxxx  
Je vous conseille aussi d’envisager un montage automatique (`autofs`) pour ce point de montage non essentiel à la bonne marche du système.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »  
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

---

<div class="post-metadata">

**Author:** ![sioban](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/53a042/32.png) [@sioban](https://www.debian-fr.org/u/sioban)\
**Post date:** [Juillet 31, 2019, 11:34 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/3 "2019-07-31T11:34:50Z")

</div>

merci je testerais ça. J’avais laissé tombé le UUID car cela m’avais causé plus d’ennuis qu’autre chose…

le point doit être monté car j’ai plusieurs services qui pointent dessus.

---

<div class="post-metadata">

**Author:** ![anon44391915](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/958977/32.png) [@anon44391915](https://www.debian-fr.org/u/anon44391915)\
**Post date:** [Juillet 31, 2019, 10:24 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/4 "2019-07-31T22:24:29Z")

</div>

Bonjour,

> [@sioban](#):
>
> le boot passe en mode emergency et me demande mon mot de passe que je rentre pour voir ce qu’il se passe. Malheureusement il ne me donne pas de shell

Étrange ceci.

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Août 2, 2019, 12:53 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/5 "2019-08-02T12:53:14Z")

</div>

> [@sioban](#):
>
> le point doit être monté car j’ai plusieurs services qui pointent dessus.

Ceci n’exclut pas un montage automatique. Par exemple, dans une grappe de machines avec `nis` et `automount` les répertoires des utilisateurs peuvent être montés à la demande depuis un serveur NFS de la grappe. Le nombre de services et d’applications qui supposent la présence d’un répertoire HOME est impressionnant, à commencer par systemd.login.  
Entre avoir un système qui ne démarre pas du tout et un système qui démarre en mode dégradé, le choix est vite fait.

EDIT: Après une modification de `/etc/fstab` il me semble sage de procéder à

```bash
update-initramfs -u 

```

et `-k all` quand cela fonctionne.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

En 2009 nous avons réduit notre endettement qui n’est plus que de 1,5 fois le cash flow  
Franck Piedelièvre le 29 janvier 2010. Les voeux du Président.

---

<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:** [Août 2, 2019, 2:12 UTC](https://www.debian-fr.org/t/probleme-fstab-depuis-mise-a-jour-vers-buster-et-noyau-4-19-37-5/79791/6 "2019-08-02T14:12:59Z")

</div>

> [@littlejohn75](#):
>
> il me semble sage de réduire les options à `defaults,noauto`

Quel est l’intérêt de combiner `defaults` avec une autre option ?  
Si le système de fichiers doit être monté au démarrage, au lieu de `noauto` j’utiliserais plutôt l’option `nofail` pour ne pas faire échouer le démarrage en cas d’échec du montage.

> [@littlejohn75](#):
>
> update-initramfs -u

Une subtilité avec laquelle je me suis fait piéger : par défaut `-u` reconstruit l’initramfs du noyau le plus récent et non du noyau actif. Pour ce dernier, utiliser `-u -k $(uname -r)`.