3 pièce(s) jointe(s)
Bug unmounting loop device
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 :
Pièce jointe 616252
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:
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" |
Pièce jointe 616251
Code:
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>... :weird:
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) :
Pièce jointe 616253
J'adore l'erreur "Error mounting ..." au démontage.
Allez comprendre...
