Discussion :

[Jipété]

Bonjour,

je ne sais pas trop où poster ça, chez Debian puisque je fais tourner bullseye 11.2 ?, ou chez Redhat puisque cette distro est + ou - à l'origine de systemd ?, et mon problème semble en rapport avec cette chose (voir le step 7 plus bas).
Par ailleurs il ne s'agit pas d'un serveur (Dieu merci !) mais d'une machine desktop.

Je suis attentif à toutes les réponses, moi je ne sais plus quoi faire, surtout après avoir fait une recherche avec "systemd umount problem" qui a fait ressortir une quantité impressionnante de problèmes liés à des comportements plus que farfelus mais en gros systemd remonte dans votre dos l'unité que vous venez de démonter, par exemple :


En ce qui me concerne, je me prends un message d'erreur lors du démontage d'un device "loopX" monté le plus simplement du monde.

Ce qui suit est en anglais, ça sera plus facile si je dois poster for the whole world !

Steps to reproduce :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# 1) verify everything's fine :
$ mount | grep ext4
/dev/sda1 on / type ext4 (rw,noatime)
/dev/sdb1 on /data type ext4 (rw,noatime)
/dev/sdc1 on /dbck type ext4 (rw,noatime)
# showing system disk, data disk and backup disk, everything's ok.
 
# 2) create a temp disk and format it :
$ truncate -s 200M /tmp/disk1.img
$ echo $?
0
$ mkfs.ext4 /tmp/disk1.img
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done                            
Creating filesystem with 204800 1k blocks and 51200 inodes
Filesystem UUID: 5264372a-4997-447d-95cf-2bc23345c42b
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729
 
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done 
 
$ echo $?
0
 
# 3) verify
$ ls -lGg /tmp/*.img
-rw-r--r-- 1 209715200 27 mars  12:23 /tmp/disk1.img
 
# 4) mount it
$ mount -o loop /tmp/disk1.img /x/  # /x is the mountpoint
 
# 5) verify
$ echo $?
0
$ mount | grep ext4
/dev/sda1 on / type ext4 (rw,noatime)
/dev/sdb1 on /data type ext4 (rw,noatime)
/dev/sdc1 on /dbck type ext4 (rw,noatime)
/tmp/disk1.img on /x type ext4 (rw,relatime)
 
# 6) everything's fine, so unmount it :
$ umount /x/ # --> display window error "Error -- The specified volume was not found"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
# 7) anyway :
$ echo $?
0
 
$ cat /var/log/syslog | tail -5 :
# 3 lines related to the mount command :
Mar 27 12:22:53 debox64 kernel: [ 4781.311756] loop: module loaded
Mar 27 12:22:53 debox64 kernel: [ 4781.326216] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
Mar 27 12:22:53 debox64 kernel: [ 4781.326224] ext4 filesystem being mounted at /x supports timestamps until 2038 (0x7fffffff)
# followed by 2 lines related to the umount, 44 seconds later (remember, "x" is the name of the mountpoint) :
Mar 27 12:23:37 debox64 systemd[1]: x.mount: Succeeded.
Mar 27 12:23:37 debox64 systemd[1149]: x.mount: Succeeded.

Dunno what these 2 last lines mean.

If I execute the previous commands in a pure console session (using Ctrl-Alt-F2 or 3 or ...), behaviour is the same except the window error message, which is not displayed, so everything looks fine, but returning in X with Alt-F7 now displays that window error, which was waiting for me to press <ENTER>...

Une idée, quelqu'un ?
Parce que cette fenêtre d'erreur dans un script, c'est très très très moyen et je n'ai pas trouvé son origine, comme si un process la faisait afficher détachée de lui et se supprimait juste après.
Pour bien faire il faudrait aller voir les "internals" de systemd (lequel ?), mais ça me dépasse un peu.

La seule piste que j'ai et qui ne me mène nulle part, c'est que la fenêtre d'erreur est une jolie fenêtre générée par gtk donc pur environnement graphique sous X, ce que je ne comprends pas car s'il y avait une vraie erreur de démontage, je devrais l'avoir dans le terminal. Non ?
Ou systemd s'est pris les pieds dans le tapis ?

EDIT :
Une précision : le problème ne se manifeste pas dans une machine virtuelle tournant sous Xfce avec un noyau 4.19.0-13 (pas tout jeune, donc) et pas plus dans une autre mv tournant sous bullseye avec un noyau 5.10.84, le problème serait donc dans mon host (aussi sous bullseye noyau 5.10.84) ?

Par contre il se produit également dans une machine MX à noyau 4.19.0-14 (donc sans systemd -- mais c'est pas vraiment vrai, il semblerait qu'il y ait des bouts qui y trainent, certains programmes ne pouvant plus s'exécuter si cet environnement n'est pas présent -- je n'ai pas creusé la question) :


J'adore l'erreur "Error mounting ..." au démontage.
Allez comprendre...

[LittleWhite]

Bonjour,

A part le fait qu'il faille faire le mount/umount avec sudo, je n'ai pas de souci. Par contre, je ne suis pas sous Debian.
Au pire, si umount est un script, vous pourriez l'ouvrir.
Je n'ai pas trop compris quelle commande entraîne le premier et le deuxième message. Par contre, je viens d'avoir l'idée qu'il est possible qu'il y ait un processus en fond, qui vérifie les points de montage pour les afficher sur le bureau.

[chrtophe]

je viens d'avoir l'idée qu'il est possible qu'il y ait un processus en fond, qui vérifie les points de montage pour les afficher sur le bureau.

Probablement le window manager

[Jipété]

Bonjour,

Au pire, si umount est un script, vous pourriez l'ouvrir.

Perdu, c'est un binaire,

Je n'ai pas trop compris quelle commande entraîne le premier et le deuxième message.

Le premier message se produit lors du démontage (umount point_de_montage) du temp disk créé pour tester.
Je rappelle l'enchainement :

1. je crée un temp disk
2. je le monte
3. je vérifie que tout va bien
4. je le démonte --> message d'erreur incohérent puisque...
5. je revérifie : il n'y a pas d'erreur et le disque est bien démonté.

(note les chiffres ci-dessus ne correspondent pas aux chiffres de l'exemple que j'ai donné, c'est juste un "ordre des choses")

Je n'ai pas trop compris quelle commande entraîne le premier et le deuxième message.

Le second message était là pour montrer que des messages d'erreur peuvent s'afficher d'une manière incohérente, en l'espèce je démonte le disque dans une machine virtuelle et ça génère une erreur de mount...
On a l'enchainement

1. mount -o loop /tmp/disk1.img /x/
2. mount | grep ext4 # pour vérifier, affiche bien le disque monté (et les autres)
3. umount /x/ --> génère un message d'erreur graphique, PAS dans la console
4. echo $?
   0 # donc tout s'est bien passé
5. mount | grep ext4 # montre que le disque a bien été démonté puisqu'il n'est plus dans la liste

Par contre, je viens d'avoir l'idée qu'il est possible qu'il y ait un processus en fond, qui vérifie les points de montage pour les afficher sur le bureau.

Probablement le window manager

Je pense aussi à ça mais je n'ai absolument pas la main là-dessus...

pour les afficher sur le bureau.

Et le pire, c'est qu'il s'agit d'options qui ne m'intéressent pas...

EDIT : clic droit / Préférences du bureau -->


En attendant, je note une chose : ça ne se produit qu'avec des devices "loop", pas avec des disques physiques.

[LittleWhite]

Si ce n'est pas le processus qui gère le bureau, c'est le navigateur de fichier (sous XFCE, je crois que c'est Thunar).
À tout hasard, n'essaieriez vous pas d'ouvrir le disque loop monté, dans votre gestionnaire de fichiers ?

[Jipété]

À tout hasard, n'essaieriez-vous pas d'ouvrir le disque loop monté, dans votre gestionnaire de fichiers ?

Non, puisque le disque est créé ex nihilo spécialement pour cette manip. Tout est bien expliqué dans les deux blocs de code du post #1.

Sinon, pensant à ce qu'on disait ce matin, j'ai regardé attentivement le man kpartx, qui m'a beaucoup amusé car on peut y lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SEE ALSO
       multipath(8) multipathd(8) hotplug(8)

Et donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ man 8 hotplug
Aucune entrée de manuel pour hotplug en section 8

Ni dans aucune autre section non plus, hein, faut pas rêver !

[Jipété]

Bonsoir,

j'ai une bonne nouvelle et une mauvaise nouvelle...

La bonne, c'est que j'ai testé ma procédure à partir de la clé live-usb qui m'a servi à installer ma distro Debian 11.2, et ça a bien fonctionné, donc la procédure telle qu'elle est décrite dans le post #1 fonctionne.

La mauvaise, c'est que je ne sais absolument pas quelle est la différence entre la distrib pure Debian et la mienne, qui est un tuning de cette pure Debian. J'ai dû virer des trucs qui me semblaient inutiles et maintenant ça va être la zermi pour remettre d'aplomb car je ne vois pas du tout comment trouver ce qui manque.

Si quelqu'un a une idée...

[gabriel21]

Avec dpkg tu peux lister tous les paquets installés sur les deux installations.
Tu renvoies vers un fichier et tu fais un diff des deux listes. Tu auras les paquets qui manquent sur ta distribution tunée. Après, investigation des paquets pour voir ceux qui ont un rapport avec mount ou udev, voir systemd...
Bon courage, car tu risque d'y passer un peu temps

[Jipété]

Bonsoir,

Merci pour le tuyau, que j'ai exploré, mais qui n'a pas été payant.
Faut dire aussi que c'est un peu l'enfer : environ 920 fichiers installés dans la machine virtuelle qui fonctionne bien, et presque 2000 dans la machine physique qui fonctionne mal...

Jouer avec diff a fait apparaitre des noms qui auraient pu être sympa, genre lvm2 ou discover, mais leur installation n'a rien donné. Et comme plein d'autres noms sont plus que non inspirants, genre libaec0 ou libgdcm3.0, alors si je dois tous les chercher et les tester un par un, j'en ai pour des mois...

D'autant plus qu'une fois cette piste explorée, il me restera encore l'option "recompil du noyau avec un module malencontreusement désélectionné par erreur" mais alors, pour trouver lequel, ça sent fort sa "mission impossible", là. Parce que mine de rien, un .config actuel, c'est pire que la meule de foin dans laquelle on a perdu son aiguille quand on n'a pas d'aimant !

Alors l'idée que j'ai, ça serait d'examiner les appels système et qu'est-ce que fait la machine au moment où j'appelle le umount.
Mais j'avoue que je n'ai pas trop de pistes -- même pas du tout, soyons honnête !

Ohé, les gens qui programment du système en C sous Linux, si vous passez par ici, vos lumières seront les bienvenues.

EDIT :
j'ai trouvé un outil, qui s'appelle strace, que j'ai appliqué dans le script à la commande umount, puis directement au script lui-même et dans les deux cas ça n'a strictement rien donné.
Conclusion : il y a un "truc" qui surveille ce qui se passe dans la machine et agit en conséquence, et je ne sais pas du tout ce que c'est...

[gabriel21]

As tu bien les 920 paquets dans ta liste de 2000 ?

J'ai fait un test avec les commandes suivante entre un Kubuntu et un ubuntu server, et la sortie est largement exploitable (5000 paquets pour le desktop et 1200 pour le server.)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
dpkg -l | grep ^ii | awk '{ print $2 " " $3}' > fichier
diff --suppress-common-lines -y fichier1 fichier2 | awk '{print $4;}' | sed -e /^$/d

Cela te fournira tous les paquets présents dans le fichier2 qui ne sont pas dans le fichier1. Dans mon test, le fichier1 correspond au desktop et le fichier2 au server et j'ai un résultat de 129 paquets qui sont sur le server et non pas sur le desktop. Si c'est un paquet manquant, tu devrais ne pas avoir trop de paquets.
Je reformate la sortie du fichier pour n'avoir que le nom du paquet et sa version.

[Jipété]

Bonjour,

et grand merci à toi de te préoccuper de mon souci, avec du code bien précis, qui m'a sorti une liste que j'ai étudiée attentivement jusqu'à ce que je me prenne un mur, : la liste m'a montré le paquet linux-image-5.10.0-10-amd64, qui doit contenir des dizaines de milliers de fichiers, je ne vois vraiment pas comment gérer ça.

D'un autre côté, je me dis que ce foutu message "Le volume indiqué n'a pas été trouvé" doit bien être quelque part dans ma machine donc, à grands coups de grep -ri "Le volume indiqu" * (ai évité les accents, bien m'en a pris, car un premier essai de la string complète n'avait rien donné), j'ai fini par recevoir grep: /usr/share/locale/fr/LC_MESSAGES/gvfs.mo: binary file matches, plus précisément

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
msgid "The given volume was not found"
msgstr "Le volume indiqué n'a pas été trouvé"

et voilà ce qu'en dit synaptic :

gvfs est un système de fichiers virtuel en espace utilisateur où les montages sont exécutés en tant que processus distincts avec lesquels on communique via D-Bus. Il contient également un module gio qui permet à toutes les applications utilisant ce dernier d'être compatibles avec gvfs.
Il permet aussi d'exposer les montages gvfs aux applications n’utilisant pas gio grâce à fuse.

Plus qu'à creuser de ce côté, par exemple en récupérant les sources pour comprendre pourquoi ce message m'est envoyé.

Mais déjà, ce qui est très curieux, c'est que ce gvfs n'est pas installé dans la machine virtuelle ! Pour comparer, ça va être tendu...

Par ailleurs, je me dis également que si ça se trouve, c'est peut-être un défaut depuis le début de l'existence de cette nouvelle machine, qui n'a pas été testée à fond car ce n'est pas tous les jours que je monte des loop devices.

À suivre avec strace sur gvfsd...

(je laisse cette note, si par hasard ça ne sert à rien ça me servira de mémoire pour savoir quoi désinstaller une fois le pb solutionné.
Par contre, en examinant les paquets gvfs, je me dis que peut-être que libglib2.0-tests pourrait être utile, alors clic droit / sélectionner pour installation et ça, ça me dit qu'il faut installer dbus-x11 et python3-dbusmock, ma foi, pourquoi pas ?)

[Jipété]

Re-bonjour,

Cet après-midi, pour me changer les idées (oui, je suis un grand malade masochiste, ), j'ai joué avec une machine virtuelle MX-Linux, qui avait besoin d'une grosse mise à jour (~ 300 paquets), et ensuite je me suis dit que j'allais voir comment se comportait mon script, puisque cette machine fonctionne à l'ancienne, sans systemd mais avec gvfsd.

Et là, surprise, je trouve une erreur dans le log qui ne s'affiche pas à l'écran, par contre le disque après démontage est remonté puisque je vois apparaitre la classique fenêtre "Nouveau périphérique inséré".

Je vous mets le script, des fois que vous voudriez jouer aussi. À la fin quelques commentaires.
La seule intervention de ce script sur la machine où il tourne est la création d'un dossier "y" à la racine du système de fichiers, et si ça ne plait pas, yakà le changer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#!/bin/bash
 
dossierdemontage="/y/"
 
mount | grep ext4
read -p "création du fichier de disque virtuel"
truncate -s 200M /tmp/aDisk.img
sync
mkfs.ext4 /tmp/aDisk.img
sync
ls -lGg /tmp/aDisk.img
read -p "montage du fichier sur $dossierdemontage"
[ ! -d "$dossierdemontage" ] && mkdir $dossierdemontage
sync
mount -o loop /tmp/aDisk.img $dossierdemontage
sync
mount | grep ext4
echo "contenu du disque virtuel :"
ls -lGg $dossierdemontage
read -p "démontage de $dossierdemontage"
umount $dossierdemontage
#strace umount $dossierdemontage
sync
cat /var/log/syslog | tail -5
 
# la fin du syslog :
# le mount (ligne 15) : (pourquoi 2 lignes ?)
#Apr  1 18:12:48 mxlinux kernel: [ 9295.771765] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
#Apr  1 18:12:59 mxlinux kernel: [ 9306.883482] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
# le démontage (ligne 21) : (pourquoi 2 lignes ?)
#Apr  1 18:15:02 mxlinux kernel: [ 9429.638662] print_req_error: I/O error, dev loop0, sector 0
#Apr  1 18:15:02 mxlinux kernel: [ 9429.638695] print_req_error: I/O error, dev loop0, sector 0
# un remontage, par qui ? Pour quoi ? et pourquoi 2 lignes ?
#Apr  1 18:17:34 mxlinux kernel: [ 9581.964514] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
#Apr  1 18:17:42 mxlinux kernel: [ 9589.488578] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

Résultat de ce remontage, l'affichage de la classique fenêtre "Périphérique amovible inséré" :


Mais ce comportement est aléatoire (j'adooooore l'informatique aléatoire et improbable, quantique, quoi ! ), regardez cet autre essai après un démontage en règle à la mano :



Attention aux 30 minutes d'écart entre les 2 lignes de la fin du précédent test à 18:38 et les 3 lignes du nouveau test à 19:08.

[Jipété]

Bonjour,

Des nouvelles :
j'ai passé le week-end à faire des tests avec des petits scripts, en résumé et pour la faire courte, la distro Q4OS (basée sur un vieux KDE) fonctionne parfaitement bien alors que la MX affiche "Périphérique amovible inséré" à l'exécution, ne démonte pas tout et génère 2 erreurs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Apr  3 16:42:55 mxlinux kernel: [ 6609.341646] print_req_error: I/O error, dev loop0, sector 0
Apr  3 16:42:55 mxlinux kernel: [ 6609.341682] print_req_error: I/O error, dev loop0, sector 0

dans les logs au démontage manuel, ce qui fait désordre.

Avec man_losetup.sh (man losetup et tout à la fin il y a un exemple), MX génère un message "Erreur L'opération a été annulée" plus des erreurs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Apr  3 12:02:52 mxlinux kernel: [ 5841.179167] print_req_error: I/O error, dev loop0, sector 2
Apr  3 12:02:52 mxlinux kernel: [ 5841.179357] EXT4-fs (loop0): unable to read superblock

dans kern.log, avec Q4OS pas d'erreurs et tout va bien.

C'est navrant, tout ça, et je sens bien qu'il ne va pas y avoir de solution universelle, il y a des milliers de posts sur le web de gens qui ont des soucis avec losetup, kpartx ou umount, faites des recherches, c'est édifiant...

En fait, au plus je manipule et au plus j'ai l'impression que mes soucis sont liés à ces gadgets de montage automatique bien agréables au demeurant mais qu'il faudrait pouvoir désactiver (exemple avec Q4OS [clic droit sur le bureau / Configurer le bureau / onglet Comportement et il me suffit de ne pas cocher "Afficher les icônes des périphériques :" en haut de l'image

], ici je n'ai capturé que les options en rapport avec mon problème, il y en a plein d'autres) et je n'ai absolument pas trouvé où ces options se cachent chez Debian.

Si quelqu'un le sait, il me (nous !) rendra un grand service en dévoilant ce secret.
S'il s'agit simplement de trifouiller des options dans un .conf (lequel ?), je prends aussi.

EDIT : Bon, j'ai finalement trouvé, dans Debian/LXDE : c'est planqué dans une option du gestionnaire de fichiers pcmanfm :


En décochant la ligne centrale, ça va beaucoup mieux !