Je viens de remarquer ce qui me semble =EAtre un bug dans la gestion des
partitions de /etc/fstab dans le cas de partitions imbriqu=E9es et aurait
aim=E9 savoir que faire de cette information.
Je m'explique=A0: j'ai r=E9cemment configur=E9 un serveur d=E9di=E9 sous Wh=
eezy,
lequel contient, entre autres, deux partitions mont=E9es sous /var/www et
/var/www/cache=A0; pour des raisons de limitations techniques de mon
h=E9bergeur, la grande firme roubaisienne, j'ai d=FB configurer d'abord la
partition mont=E9e sous /var/www/cache, large d'environ 124 Gio, puis la
partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www
=E9tait situ=E9e apr=E8s /var/www/cache dans /etc/fstab.
=C0 ce stade, les plus aguerris d'entre vous devraient entrevoir mon
probl=E8me=A0: cela a donn=E9 lieu =E0 un fonctionnement tr=E8s erratique d=
e la
partition /var/www/cache, comme les commandes ci-dessous, ex=E9cut=E9es
juste apr=E8s un red=E9marrage du serveur, attestent=A0:
david@Curunir:~$ df -h
Sys. fich. Taille Util. Dispo Uti% Mont=E9 sur
rootfs 54G 3,1G 49G 6% /
udev 10M 0 10M 0% /dev
tmpfs 13G 328K 13G 1% /run
/dev/md1 54G 3,1G 49G 6% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 35G 0 35G 0% /dev/shm
/dev/md3 20G 233M 19G 2% /var/log
/dev/md4 1,7T 852M 1,6T 1% /var/www/cache
/dev/md6 99G 188M 94G 1% /home
/dev/md7 1,7T 852M 1,6T 1% /var/www
tmpfs 32G 0 32G 0% /tmp
david@Curunir:~$ sudo su
[sudo] password for david:=20
root@Curunir:/home/david# umount /dev/md4
umount: /var/www/cache: not mounted
root@Curunir:/home/david# mount /dev/md4
root@Curunir:/home/david# df -h
Sys. fich. Taille Util. Dispo Uti% Mont=E9 sur
rootfs 54G 3,1G 49G 6% /
udev 10M 0 10M 0% /dev
tmpfs 13G 328K 13G 1% /run
/dev/md1 54G 3,1G 49G 6% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 35G 0 35G 0% /dev/shm
/dev/md3 20G 233M 19G 2% /var/log
/dev/md4 124G 188M 118G 1% /var/www/cache
/dev/md6 99G 188M 94G 1% /home
/dev/md7 1,7T 852M 1,6T 1% /var/www
tmpfs 32G 4,0K 32G 1% /tmp
/dev/md4 124G 188M 118G 1% /var/www/cache
root@Curunir:/home/david# uname -a
Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux
root@Curunir:/home/david# aptitude show linux-image-3.2.0-4-amd64
Paquet=A0: linux-image-3.2.0-4-amd64 =20
Nouveau: oui
=C9tat: install=E9
Automatiquement install=E9: oui
Version=A0: 3.2.57-3
Priorit=E9=A0: optionnel
Section=A0: kernel
Responsable=A0: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture=A0: amd64
Taille d=E9compress=E9e=A0: 106 M
D=E9pend: kmod | module-init-tools, linux-base (>=3D 3~), initramfs-tools
(>=3D 0.99~) | linux-initramfs-tool
Pr=E9-d=E9pend: debconf | debconf-2.0
Recommande: firmware-linux-free (>=3D 3~)
Sugg=E8re: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux |
lilo
Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~)
Fournit: linux-image, linux-modules-3.2.0-4-amd64
Description=A0: Linux 3.2 for 64-bit PCs
The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or
VIA Nano processors.=20
=20
This kernel also runs on a Xen hypervisor. It supports both
privileged (dom0) and unprivileged (domU) operation.
Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque
journal que ce soit=A0; apr=E8s de nombreux essais, je me suis souvenu de
l'ordre de ces partitions dans /etc/fstab et les ai invers=E9es pour
placer /var/www avant /var/www/cache, et la partition /var/www/cache a,
de ce fait, retrouv=E9 un comportement normal.
Je sais que l'ordre dans /etc/fstab des syst=E8mes de fichiers =E0 monter
est important, mais je n'aurais jamais pens=E9 que des probl=E8mes li=E9s
pourraient se montrer de la sorte, sans aucun avertissement ni gestion
correcte par le noyau. =C0 mon sens, le noyau devrait g=E9rer ce genre de
cas de fa=E7on transparente, par exemple en chargeant /etc/fstab d'un bloc
et en en v=E9rifiant le contenu pour remettre dans l'ordre le montage des
partitions afin d'=E9viter les probl=E8mes=A0; sinon, il devrait au moins =
=EAtre
capable d'avertir de ce genre de situation par un message dans les
journaux afin d'=E9viter de perdre des heures d'analyse de sympt=F4mes
sibyllins pour un probl=E8me aussi trivial.
J'en arrive maintenant au moment fatidique=A0: que dois-je faire de ce
probl=E8me=A0? Tout d'abord, est-ce bien un bug ou est-ce une
fonctionnalit=E9=A0? Si c'est bien un bug, =E0 qui le signaler=A0? Dois-je =
le
signaler d'abord =E0 l'=E9quipe Debian qui le remontra aux d=E9veloppeurs du
noyau si n=E9cessaire, ou dois-je le signaler directement aux d=E9veloppeurs
du noyau puisque cela concerne la fonction bas niveau de gestion du
montage des disques=A0?
Si vous =EAtes arriv=E9s jusqu'=E0 cette phrase, merci de m'avoir lu et mer=
ci
d'avance pour votre =E9clairage.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140512122214.GF31205@europecamions-interactive.com
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information.
Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy, lequel contient, entre autres, deux partitions montées sous /var/www et /var/www/cache ; pour des raisons de limitations techniques de mon hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la partition montée sous /var/www/cache, large d'environ 124 Gio, puis la partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www était située après /var/www/cache dans /etc/fstab.
À ce stade, les plus aguerris d'entre vous devraient entrevoir mon problème : cela a donné lieu à un fonctionnement très erratique de la partition /var/www/cache, comme les commandes ci-dessous, exécutées juste après un redémarrage du serveur, attestent : :~$ df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 1,7T 852M 1,6T 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 0 32G 0% /tmp :~$ sudo su [sudo] password for david: :/home/david# umount /dev/md4 umount: /var/www/cache: not mounted :/home/david# mount /dev/md4 :/home/david# df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 124G 188M 118G 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 4,0K 32G 1% /tmp /dev/md4 124G 188M 118G 1% /var/www/cache :/home/david# uname -a Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux :/home/david# aptitude show linux-image-3.2.0-4-amd64 Paquet : linux-image-3.2.0-4-amd64 Nouveau: oui État: installé Automatiquement installé: oui Version : 3.2.57-3 Priorité : optionnel Section : kernel Responsable : Debian Kernel Team Architecture : amd64 Taille décompressée : 106 M Dépend: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools (>= 0.99~) | linux-initramfs-tool Pré-dépend: debconf | debconf-2.0 Recommande: firmware-linux-free (>= 3~) Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux | lilo Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~) Fournit: linux-image, linux-modules-3.2.0-4-amd64 Description : Linux 3.2 for 64-bit PCs The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or VIA Nano processors.
This kernel also runs on a Xen hypervisor. It supports both privileged (dom0) and unprivileged (domU) operation.
Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque journal que ce soit ; après de nombreux essais, je me suis souvenu de l'ordre de ces partitions dans /etc/fstab et les ai inversées pour placer /var/www avant /var/www/cache, et la partition /var/www/cache a, de ce fait, retrouvé un comportement normal.
Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter est important, mais je n'aurais jamais pensé que des problèmes liés pourraient se montrer de la sorte, sans aucun avertissement ni gestion correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc et en en vérifiant le contenu pour remettre dans l'ordre le montage des partitions afin d'éviter les problèmes ; sinon, il devrait au moins être capable d'avertir de ce genre de situation par un message dans les journaux afin d'éviter de perdre des heures d'analyse de symptômes sibyllins pour un problème aussi trivial.
J'en arrive maintenant au moment fatidique : que dois-je faire de ce problème ? Tout d'abord, est-ce bien un bug ou est-ce une fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-j e le signaler d'abord à l'équipe Debian qui le remontra aux développeurs du noyau si nécessaire, ou dois-je le signaler directement aux développe urs du noyau puisque cela concerne la fonction bas niveau de gestion du montage des disques ?
Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et m erci d'avance pour votre éclairage.
Cordialement.
Bonjour,
D'expérience, mount a deux modes de fonctionnements, le mode séquentiel (appelé par mount -a), où l'ordre suivi est de haut en bas dans fstab, et l'ordre forké (mount -F) où une instance de mount est lancée par part oche, et où c'est plus ou moins la fête du slip.
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions imbriquées, et fait un mount -a au boot (en tout cas dans l'init script q ue j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le carac tère « basique » du problème, j'aurais tendance à dire que c'est un comportement qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c' est de mettre une option noauto sur les partitions problématiques, et de les mon ter via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
-- PEB
--PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des
partitions de /etc/fstab dans le cas de partitions imbriquées et aurait
aimé savoir que faire de cette information.
Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy,
lequel contient, entre autres, deux partitions montées sous /var/www et
/var/www/cache ; pour des raisons de limitations techniques de mon
hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la
partition montée sous /var/www/cache, large d'environ 124 Gio, puis la
partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www
était située après /var/www/cache dans /etc/fstab.
À ce stade, les plus aguerris d'entre vous devraient entrevoir mon
problème : cela a donné lieu à un fonctionnement très erratique de la
partition /var/www/cache, comme les commandes ci-dessous, exécutées
juste après un redémarrage du serveur, attestent :
david@Curunir:~$ df -h
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 54G 3,1G 49G 6% /
udev 10M 0 10M 0% /dev
tmpfs 13G 328K 13G 1% /run
/dev/md1 54G 3,1G 49G 6% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 35G 0 35G 0% /dev/shm
/dev/md3 20G 233M 19G 2% /var/log
/dev/md4 1,7T 852M 1,6T 1% /var/www/cache
/dev/md6 99G 188M 94G 1% /home
/dev/md7 1,7T 852M 1,6T 1% /var/www
tmpfs 32G 0 32G 0% /tmp
david@Curunir:~$ sudo su
[sudo] password for david:
root@Curunir:/home/david# umount /dev/md4
umount: /var/www/cache: not mounted
root@Curunir:/home/david# mount /dev/md4
root@Curunir:/home/david# df -h
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 54G 3,1G 49G 6% /
udev 10M 0 10M 0% /dev
tmpfs 13G 328K 13G 1% /run
/dev/md1 54G 3,1G 49G 6% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 35G 0 35G 0% /dev/shm
/dev/md3 20G 233M 19G 2% /var/log
/dev/md4 124G 188M 118G 1% /var/www/cache
/dev/md6 99G 188M 94G 1% /home
/dev/md7 1,7T 852M 1,6T 1% /var/www
tmpfs 32G 4,0K 32G 1% /tmp
/dev/md4 124G 188M 118G 1% /var/www/cache
root@Curunir:/home/david# uname -a
Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux
root@Curunir:/home/david# aptitude show linux-image-3.2.0-4-amd64
Paquet : linux-image-3.2.0-4-amd64
Nouveau: oui
État: installé
Automatiquement installé: oui
Version : 3.2.57-3
Priorité : optionnel
Section : kernel
Responsable : Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture : amd64
Taille décompressée : 106 M
Dépend: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools
(>= 0.99~) | linux-initramfs-tool
Pré-dépend: debconf | debconf-2.0
Recommande: firmware-linux-free (>= 3~)
Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux |
lilo
Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~)
Fournit: linux-image, linux-modules-3.2.0-4-amd64
Description : Linux 3.2 for 64-bit PCs
The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or
VIA Nano processors.
This kernel also runs on a Xen hypervisor. It supports both
privileged (dom0) and unprivileged (domU) operation.
Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque
journal que ce soit ; après de nombreux essais, je me suis souvenu de
l'ordre de ces partitions dans /etc/fstab et les ai inversées pour
placer /var/www avant /var/www/cache, et la partition /var/www/cache a,
de ce fait, retrouvé un comportement normal.
Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter
est important, mais je n'aurais jamais pensé que des problèmes liés
pourraient se montrer de la sorte, sans aucun avertissement ni gestion
correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de
cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc
et en en vérifiant le contenu pour remettre dans l'ordre le montage des
partitions afin d'éviter les problèmes ; sinon, il devrait au moins être
capable d'avertir de ce genre de situation par un message dans les
journaux afin d'éviter de perdre des heures d'analyse de symptômes
sibyllins pour un problème aussi trivial.
J'en arrive maintenant au moment fatidique : que dois-je faire de ce
problème ? Tout d'abord, est-ce bien un bug ou est-ce une
fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-j e le
signaler d'abord à l'équipe Debian qui le remontra aux développeurs du
noyau si nécessaire, ou dois-je le signaler directement aux développe urs
du noyau puisque cela concerne la fonction bas niveau de gestion du
montage des disques ?
Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et m erci
d'avance pour votre éclairage.
Cordialement.
Bonjour,
D'expérience, mount a deux modes de fonctionnements, le mode séquentiel
(appelé par mount -a), où l'ordre suivi est de haut en bas dans fstab, et
l'ordre forké (mount -F) où une instance de mount est lancée par part oche,
et où c'est plus ou moins la fête du slip.
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions
imbriquées, et fait un mount -a au boot (en tout cas dans l'init script q ue
j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je
remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le carac tère
« basique » du problème, j'aurais tendance à dire que c'est un comportement
qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c' est de
mettre une option noauto sur les partitions problématiques, et de les mon ter
via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des
retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
--
PEB
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140512131436.GK10796@crans.org
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information.
Je m'explique : j'ai récemment configuré un serveur dédié sous Wheezy, lequel contient, entre autres, deux partitions montées sous /var/www et /var/www/cache ; pour des raisons de limitations techniques de mon hébergeur, la grande firme roubaisienne, j'ai dû configurer d'abord la partition montée sous /var/www/cache, large d'environ 124 Gio, puis la partition /var/www, large d'environ 1,7 Tio, ce qui fait que /var/www était située après /var/www/cache dans /etc/fstab.
À ce stade, les plus aguerris d'entre vous devraient entrevoir mon problème : cela a donné lieu à un fonctionnement très erratique de la partition /var/www/cache, comme les commandes ci-dessous, exécutées juste après un redémarrage du serveur, attestent : :~$ df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 1,7T 852M 1,6T 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 0 32G 0% /tmp :~$ sudo su [sudo] password for david: :/home/david# umount /dev/md4 umount: /var/www/cache: not mounted :/home/david# mount /dev/md4 :/home/david# df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 54G 3,1G 49G 6% / udev 10M 0 10M 0% /dev tmpfs 13G 328K 13G 1% /run /dev/md1 54G 3,1G 49G 6% / tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 35G 0 35G 0% /dev/shm /dev/md3 20G 233M 19G 2% /var/log /dev/md4 124G 188M 118G 1% /var/www/cache /dev/md6 99G 188M 94G 1% /home /dev/md7 1,7T 852M 1,6T 1% /var/www tmpfs 32G 4,0K 32G 1% /tmp /dev/md4 124G 188M 118G 1% /var/www/cache :/home/david# uname -a Linux Curunir 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux :/home/david# aptitude show linux-image-3.2.0-4-amd64 Paquet : linux-image-3.2.0-4-amd64 Nouveau: oui État: installé Automatiquement installé: oui Version : 3.2.57-3 Priorité : optionnel Section : kernel Responsable : Debian Kernel Team Architecture : amd64 Taille décompressée : 106 M Dépend: kmod | module-init-tools, linux-base (>= 3~), initramfs-tools (>= 0.99~) | linux-initramfs-tool Pré-dépend: debconf | debconf-2.0 Recommande: firmware-linux-free (>= 3~) Suggère: linux-doc-3.2, debian-kernel-handbook, grub-pc | extlinux | lilo Casse: at (< 3.1.12-1+squeeze1), initramfs-tools (< 0.99~) Fournit: linux-image, linux-modules-3.2.0-4-amd64 Description : Linux 3.2 for 64-bit PCs The Linux kernel 3.2 and modules for use on PCs with AMD64, Intel 64 or VIA Nano processors.
This kernel also runs on a Xen hypervisor. It supports both privileged (dom0) and unprivileged (domU) operation.
Ce comportement ne s'accompagnait d'aucun message d'erreur dans quelque journal que ce soit ; après de nombreux essais, je me suis souvenu de l'ordre de ces partitions dans /etc/fstab et les ai inversées pour placer /var/www avant /var/www/cache, et la partition /var/www/cache a, de ce fait, retrouvé un comportement normal.
Je sais que l'ordre dans /etc/fstab des systèmes de fichiers à monter est important, mais je n'aurais jamais pensé que des problèmes liés pourraient se montrer de la sorte, sans aucun avertissement ni gestion correcte par le noyau. À mon sens, le noyau devrait gérer ce genre de cas de façon transparente, par exemple en chargeant /etc/fstab d'un bloc et en en vérifiant le contenu pour remettre dans l'ordre le montage des partitions afin d'éviter les problèmes ; sinon, il devrait au moins être capable d'avertir de ce genre de situation par un message dans les journaux afin d'éviter de perdre des heures d'analyse de symptômes sibyllins pour un problème aussi trivial.
J'en arrive maintenant au moment fatidique : que dois-je faire de ce problème ? Tout d'abord, est-ce bien un bug ou est-ce une fonctionnalité ? Si c'est bien un bug, à qui le signaler ? Dois-j e le signaler d'abord à l'équipe Debian qui le remontra aux développeurs du noyau si nécessaire, ou dois-je le signaler directement aux développe urs du noyau puisque cela concerne la fonction bas niveau de gestion du montage des disques ?
Si vous êtes arrivés jusqu'à cette phrase, merci de m'avoir lu et m erci d'avance pour votre éclairage.
Cordialement.
Bonjour,
D'expérience, mount a deux modes de fonctionnements, le mode séquentiel (appelé par mount -a), où l'ordre suivi est de haut en bas dans fstab, et l'ordre forké (mount -F) où une instance de mount est lancée par part oche, et où c'est plus ou moins la fête du slip.
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions imbriquées, et fait un mount -a au boot (en tout cas dans l'init script q ue j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le carac tère « basique » du problème, j'aurais tendance à dire que c'est un comportement qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c' est de mettre une option noauto sur les partitions problématiques, et de les mon ter via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
-- PEB
--PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Jacques Daniel
Le 12/05/2014 15:14, Pierre-Elliott Bécue a écrit :
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information.
...
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions imbriquées, et fait un mount -a au boot (en tout cas dans l'init script que j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le caractère « basique » du problème, j'aurais tendance à dire que c'est un comportement qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c'est de mettre une option noauto sur les partitions problématiques, et de les monter via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
Bonjour
man mount confirme l'expérience de Pierre-Elliott: -a, --all Monter tous les systèmes de fichiers (d'un type donné) mention‐ nés dans fstab.
-F, --fork (Utilisée conjointement avec -a) lancer un processus mount pour chaque périphérique. Cela effectuera le montage en parallèle des divers périphériques ou serveurs NFS. L'avantage est la rapi‐ dité ; de plus les délais de NFS s'écoulent en parallèle. Un désavantage est que les montages ont lieu dans le désordre. Il ne faut donc pas utiliser cette option pour monter à la fois /usr et /usr/spool.
Il convient donc de décrire les montages dans le bon ordre dans fstab. Si signalement il doit y avoir ce n'est donc pas au niveau "bug" mais au niveau "Wishlist item" ... avec à mon avis peu de chance de réalisation (au boot c'est bien mount -a qui est réalisé et pas mount -aF)
A+
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 12/05/2014 15:14, Pierre-Elliott Bécue a écrit :
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des
partitions de /etc/fstab dans le cas de partitions imbriquées et aurait
aimé savoir que faire de cette information.
...
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions
imbriquées, et fait un mount -a au boot (en tout cas dans l'init script que
j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je
remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le caractère
« basique » du problème, j'aurais tendance à dire que c'est un comportement
qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c'est de
mettre une option noauto sur les partitions problématiques, et de les monter
via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des
retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
Bonjour
man mount confirme l'expérience de Pierre-Elliott:
-a, --all
Monter tous les systèmes de fichiers (d'un type donné) mention‐
nés dans fstab.
-F, --fork
(Utilisée conjointement avec -a) lancer un processus mount pour
chaque périphérique. Cela effectuera le montage en parallèle des
divers périphériques ou serveurs NFS. L'avantage est la rapi‐
dité ; de plus les délais de NFS s'écoulent en parallèle. Un
désavantage est que les montages ont lieu dans le désordre. Il
ne faut donc pas utiliser cette option pour monter à la fois
/usr et /usr/spool.
Il convient donc de décrire les montages dans le bon ordre dans fstab.
Si signalement il doit y avoir ce n'est donc pas au niveau "bug" mais au
niveau "Wishlist item" ... avec à mon avis peu de chance de réalisation
(au boot c'est bien mount -a qui est réalisé et pas mount -aF)
A+
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5370D51B.40506@hermine.no-ip.info
Le 12/05/2014 15:14, Pierre-Elliott Bécue a écrit :
On lun. 12 mai 2014 à 14:22:14, David Guyot wrote:
Bonjour, la liste.
Je viens de remarquer ce qui me semble être un bug dans la gestion des partitions de /etc/fstab dans le cas de partitions imbriquées et aurait aimé savoir que faire de cette information.
...
De ce que je sais, mount n'a pas une exceptionnelle gestion des partitions imbriquées, et fait un mount -a au boot (en tout cas dans l'init script que j'ai sur le serveur sur lequel je viens de vérifier), mais aussi loin que je remonte, je n'ai jamais eu le « pourquoi » de la chose. Vu le caractère « basique » du problème, j'aurais tendance à dire que c'est un comportement qui, s'il n'est pas voulu, ne gêne pas grand monde.
Une solution « infaillible » (que je n'emploie pas, par flemme), c'est de mettre une option noauto sur les partitions problématiques, et de les monter via un rc.local qui sera, lui, bien ordonné.
Quant au signalement, je pense que le mieux est d'abord d'obtenir des retours d'autres utilisateurs, donc en parler ici me semble bien.
Bonne suite,
Bonjour
man mount confirme l'expérience de Pierre-Elliott: -a, --all Monter tous les systèmes de fichiers (d'un type donné) mention‐ nés dans fstab.
-F, --fork (Utilisée conjointement avec -a) lancer un processus mount pour chaque périphérique. Cela effectuera le montage en parallèle des divers périphériques ou serveurs NFS. L'avantage est la rapi‐ dité ; de plus les délais de NFS s'écoulent en parallèle. Un désavantage est que les montages ont lieu dans le désordre. Il ne faut donc pas utiliser cette option pour monter à la fois /usr et /usr/spool.
Il convient donc de décrire les montages dans le bon ordre dans fstab. Si signalement il doit y avoir ce n'est donc pas au niveau "bug" mais au niveau "Wishlist item" ... avec à mon avis peu de chance de réalisation (au boot c'est bien mount -a qui est réalisé et pas mount -aF)
A+
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le lundi 12 mai 2014 à 22:27:18 +0200, Jacques Daniel a écrit:
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour. > > Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les > problèmes liés à un mauvais ordre de montage ne sont pas claireme nt > indiqués ; un élément aussi important du système ne devrait-il pas être > doté d'avertissements dans les pages man ou dans les journaux systè me > lorsqu'un problème se produit ? J'ai du mal à trouver normal que le > noyau accepte sans broncher de mettre les partitions dans un état > incohérent ; habituellement, sous GNU/Linux, quand de telles > possibilités sont laissées à root, elles sont entourées d'un lu xe de > messages d'avertissement du genre « Attention, vous allez probablement > endommager votre système si vous continuez ! », mais, ici, rien, le > noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le > bazar derrière. > > Aurais-je manqué quelque chose ? > > Merci d'avance. > > Cordialement. >
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me peut être une fonctionnalité intéressante et où le comportement e st alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis /var/www/cache) et pour des raisons d'exploitation tu désires mettre en place temporairement un autre environnement (la nuit, le week-end ... ou environnement dégradé suite à incident ... ou ...) et alors tu éc rases temporairement ton environnement en montant un autre système de fichiers /var/www (sans le besoin du cache). Quand tu veux reveveuwnir dans l'environnement initial tu as juste à démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas (c'est bien le principe même du montage d'un système de fichiers: ren dre visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
Bonjour.
Effectivement, ta réponse est pertinente, mais je continue de croire que le noyau devrait au moins avertir des conséquences d'un tel ordre de montage des partitions. Je vais demander l'ajout de cet avertissement ; dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du noyau ?
Merci d'avance pour ta réponse, ou celle d'un autre, bien sûr.
Le lundi 12 mai 2014 à 22:27:18 +0200, Jacques Daniel a écrit:
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour.
>
> Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les
> problèmes liés à un mauvais ordre de montage ne sont pas claireme nt
> indiqués ; un élément aussi important du système ne devrait-il pas être
> doté d'avertissements dans les pages man ou dans les journaux systè me
> lorsqu'un problème se produit ? J'ai du mal à trouver normal que le
> noyau accepte sans broncher de mettre les partitions dans un état
> incohérent ; habituellement, sous GNU/Linux, quand de telles
> possibilités sont laissées à root, elles sont entourées d'un lu xe de
> messages d'avertissement du genre « Attention, vous allez probablement
> endommager votre système si vous continuez ! », mais, ici, rien, le
> noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le
> bazar derrière.
>
> Aurais-je manqué quelque chose ?
>
> Merci d'avance.
>
> Cordialement.
>
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me
peut être une fonctionnalité intéressante et où le comportement e st
alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis
/var/www/cache) et pour des raisons d'exploitation tu désires mettre en
place temporairement un autre environnement (la nuit, le week-end ... ou
environnement dégradé suite à incident ... ou ...) et alors tu éc rases
temporairement ton environnement en montant un autre système de fichiers
/var/www (sans le besoin du cache).
Quand tu veux reveveuwnir dans l'environnement initial tu as juste à
démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas
(c'est bien le principe même du montage d'un système de fichiers: ren dre
visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention
de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
Bonjour.
Effectivement, ta réponse est pertinente, mais je continue de croire que
le noyau devrait au moins avertir des conséquences d'un tel ordre de
montage des partitions. Je vais demander l'ajout de cet avertissement ;
dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du
noyau ?
Merci d'avance pour ta réponse, ou celle d'un autre, bien sûr.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140513081938.GI31205@europecamions-interactive.com
Le lundi 12 mai 2014 à 22:27:18 +0200, Jacques Daniel a écrit:
Le 12/05/2014 16:37, David Guyot a écrit :
> Bonjour. > > Merci pour vos réponses. Toutefois, je ne comprends pas pourquoi les > problèmes liés à un mauvais ordre de montage ne sont pas claireme nt > indiqués ; un élément aussi important du système ne devrait-il pas être > doté d'avertissements dans les pages man ou dans les journaux systè me > lorsqu'un problème se produit ? J'ai du mal à trouver normal que le > noyau accepte sans broncher de mettre les partitions dans un état > incohérent ; habituellement, sous GNU/Linux, quand de telles > possibilités sont laissées à root, elles sont entourées d'un lu xe de > messages d'avertissement du genre « Attention, vous allez probablement > endommager votre système si vous continuez ! », mais, ici, rien, le > noyau prend ce qu'on lui donne sans vérifier et tant pis si ça met le > bazar derrière. > > Aurais-je manqué quelque chose ? > > Merci d'avance. > > Cordialement. >
Bonsoir,
On peut imaginer des situations où ce que tu trouves être un problè me peut être une fonctionnalité intéressante et où le comportement e st alors tout à fait souhaitable:
tu as un environnement de production (avec montage de /var/www puis /var/www/cache) et pour des raisons d'exploitation tu désires mettre en place temporairement un autre environnement (la nuit, le week-end ... ou environnement dégradé suite à incident ... ou ...) et alors tu éc rases temporairement ton environnement en montant un autre système de fichiers /var/www (sans le besoin du cache). Quand tu veux reveveuwnir dans l'environnement initial tu as juste à démonter /var/www et tu retrouves ton environnement initial.
D'accord c'est sans doute un peu tiré par les cheveux mais pourquoi pas (c'est bien le principe même du montage d'un système de fichiers: ren dre visible le nouveau système de fichiers et cacher l'ancienne arborescenc e).
On pourrait effectivement imaginer des warnings pour attirer l'attention de cette situation qui dans d'autres circonstances porte à confusion,
Cordialement
Jacques
PS: si tu le juges utile tu peux poster ma réponse sur la liste
Bonjour.
Effectivement, ta réponse est pertinente, mais je continue de croire que le noyau devrait au moins avertir des conséquences d'un tel ordre de montage des partitions. Je vais demander l'ajout de cet avertissement ; dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du noyau ?
Merci d'avance pour ta réponse, ou celle d'un autre, bien sûr.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/34147935.oVMivD07vy@earendil
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Stéphane GARGOLY
Bonjour à tous les utilisateurs et développeurs de Debian :
Le mardi 13 mai 2014 à 08:19, David Guyot interactive.com> a écrit :
Effectivement, ta réponse est pertinente, mais je continue de croire que le noyau devrait au moins avertir des conséquences d'un tel ordre de montage des partitions. Je vais demander l'ajout de cet avertissement ; dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du noyau ?
Envoie plutôt au(x) responsable(s) Debian (par l'intermédiaire de 'repo rtbug' et en anglais) avec un niveau de gravité (ligne 'Severity: ') noté à "wishlist" (liste de souhaits) car il s'agit, à priori, d'une demande d'u ne nouvelle fonctionnalité.
Pour plus d'informations, voir la page "Comment signaler un bogue dans Debi an avec reportbug" : http://www.debian.org/Bugs/Reporting
Par la suite, ce(s) même(s) responsable(s) se chargeront probablement de se mettre en relation avec les développeurs du noyau Linux - jusqu'à Linus Torvalds ? - pour voir de ce qu'on peut faire par rapport à ta demande...
Je dis cela car il n'est pas sûr que ton souhait soit jugé plus importa nt ou prioritaire (par les mainteneurs ou les développeurs) par rapport aux aut res tâches qui leurs sont imposées...
Cordialement et à bientôt,
Stéphane.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Bonjour à tous les utilisateurs et développeurs de Debian :
Le mardi 13 mai 2014 à 08:19, David Guyot <david.guyot@europecamions-
interactive.com> a écrit :
Effectivement, ta réponse est pertinente, mais je continue de croire que
le noyau devrait au moins avertir des conséquences d'un tel ordre de
montage des partitions. Je vais demander l'ajout de cet avertissement ;
dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du
noyau ?
Envoie plutôt au(x) responsable(s) Debian (par l'intermédiaire de 'repo rtbug'
et en anglais) avec un niveau de gravité (ligne 'Severity: ') noté à
"wishlist" (liste de souhaits) car il s'agit, à priori, d'une demande d'u ne
nouvelle fonctionnalité.
Pour plus d'informations, voir la page "Comment signaler un bogue dans Debi an
avec reportbug" : http://www.debian.org/Bugs/Reporting
Par la suite, ce(s) même(s) responsable(s) se chargeront probablement de se
mettre en relation avec les développeurs du noyau Linux - jusqu'à Linus
Torvalds ? - pour voir de ce qu'on peut faire par rapport à ta demande...
Je dis cela car il n'est pas sûr que ton souhait soit jugé plus importa nt ou
prioritaire (par les mainteneurs ou les développeurs) par rapport aux aut res
tâches qui leurs sont imposées...
Cordialement et à bientôt,
Stéphane.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/201405130852.04581.stephane.gargoly@gmail.com
Bonjour à tous les utilisateurs et développeurs de Debian :
Le mardi 13 mai 2014 à 08:19, David Guyot interactive.com> a écrit :
Effectivement, ta réponse est pertinente, mais je continue de croire que le noyau devrait au moins avertir des conséquences d'un tel ordre de montage des partitions. Je vais demander l'ajout de cet avertissement ; dois-je envoyer cette demande à l'équipe Debian ou aux développeurs du noyau ?
Envoie plutôt au(x) responsable(s) Debian (par l'intermédiaire de 'repo rtbug' et en anglais) avec un niveau de gravité (ligne 'Severity: ') noté à "wishlist" (liste de souhaits) car il s'agit, à priori, d'une demande d'u ne nouvelle fonctionnalité.
Pour plus d'informations, voir la page "Comment signaler un bogue dans Debi an avec reportbug" : http://www.debian.org/Bugs/Reporting
Par la suite, ce(s) même(s) responsable(s) se chargeront probablement de se mettre en relation avec les développeurs du noyau Linux - jusqu'à Linus Torvalds ? - pour voir de ce qu'on peut faire par rapport à ta demande...
Je dis cela car il n'est pas sûr que ton souhait soit jugé plus importa nt ou prioritaire (par les mainteneurs ou les développeurs) par rapport aux aut res tâches qui leurs sont imposées...
Cordialement et à bientôt,
Stéphane.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/201405130912.57006.stephane.gargoly@gmail.com
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140513155759.3d5f84ea@anubis.defcon1
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140513144617.GQ31205@europecamions-interactive.com
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Bernard Isambert
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit: Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
simple, on pourrait s'attendre à ce que le système avertisse de ce problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des avertissements pour moins que ça, et, mount étant une commande esse ntielle, elle pourrait se permettre d'être plus bavarde que de simplement fair e ce qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
De même.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
simple, on pourrait s'attendre à ce que le système avertisse de ce
problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des
avertissements pour moins que ça, et, mount étant une commande esse ntielle,
elle pourrait se permettre d'être plus bavarde que de simplement fair e ce
qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
De même.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/5372330F.4020103@taranig.net
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit: Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est s i
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
simple, on pourrait s'attendre à ce que le système avertisse de ce problème, à mon humble avis ; j'ai déjà vu des logiciels lancer des avertissements pour moins que ça, et, mount étant une commande esse ntielle, elle pourrait se permettre d'être plus bavarde que de simplement fair e ce qu'on lui dit sans avertir de problèmes potentiels.
Cordialement.
De même.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Francois Lafont
Le 13/05/2014 16:58, Bernard Isambert a écrit :
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit: Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
David ne parle pas de corriger un bug, il souhaiterait simplement que la commande mount puisse fournir un message d'erreur un peu éclairant dans le cas d'un ordre malencontreux dans le fichier fstab. Sur le principe, je ne vois vraiment pas en quoi cela est illégitime.
-- François Lafont
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/lktf0a$o8$
Le 13/05/2014 16:58, Bernard Isambert a écrit :
Le 13/05/2014 16:46, David Guyot a écrit :
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
David ne parle pas de corriger un bug, il souhaiterait simplement
que la commande mount puisse fournir un message d'erreur un peu
éclairant dans le cas d'un ordre malencontreux dans le fichier fstab.
Sur le principe, je ne vois vraiment pas en quoi cela est illégitime.
--
François Lafont
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/lktf0a$o8$1@ger.gmane.org
Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit: Il faut d'abord penser à vérifier /etc/fstab ; malheureusement, au moins chez mon hébergeur, c'est leur installeur qui génère /etc/fstab, donc on n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
C'est donc chez votre hébergeur qu'est le bug et pas ailleurs.
David ne parle pas de corriger un bug, il souhaiterait simplement que la commande mount puisse fournir un message d'erreur un peu éclairant dans le cas d'un ordre malencontreux dans le fichier fstab. Sur le principe, je ne vois vraiment pas en quoi cela est illégitime.
-- François Lafont
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/lktf0a$o8$
