/etc/fstab et partitions imbriquées : bug ou fonctionnalité ?

Le
David Guyot
--+Z7/5fzWRHDJ0o7Q
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 Wh=
eezy,
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 d=
e 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-je =
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éveloppeurs
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 mer=
ci
d'avance pour votre éclairage.

Cordialement.
--
David Guyot
Administrateur système, réseau et télécommunications / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
Tel: +33 (0)3 29 30 47 85
Fax : +33 (0)3 29 31 31 31

--+Z7/5fzWRHDJ0o7Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

--BEGIN PGP SIGNATURE--
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTcLz2AAoJEOdwVf06csTSmXsP/3qSxbMCokS1o2iVg3vBNBfA
KkcXyqvu8W/8OhdfhrEaHrZ1HafFmmajWIZiHMQrkwr/wLpCNta3D9M1s070fDFb
xxL39TiI4pKmpwgGrOUpoV4322tfo0+fdiF2yVPIQ6h72wklr1PTZl3Qa2bMxUfQ
WaHmXxs0fbw1ZWBrCgn1386+87oDdppjQe9liDQPAsgvbJCnpbKRJ+wz3hHM8GZA
5Dcr8JTpigkdQiEMfA7GuBlVEN5+Vq3TeuRjoB11FVUWT05/lAvHOVPbRgfM9JUQ
BHSkDfX3iSwFD+cQ1a/AoAUub33rxyUzzYv8gMU6dZp60234pg/OHdvZgv5Hg3Dc
xOoG8ve1yFZMay3/9Rqc2ov9QENFoxbBDsKYDIXl3ZaEBGlvkI7escFpQinGIwP2
d+T2U3/yh0EqPTTbGviS+lj5OIEcUHDgn728L62PjUKqvpPILtvtyh2I0eWgdKo7
DFldAmwHJYEwc1XAmmH8/D4yLse1it+57lpODgJc+LIECU86gtJ7Q9qNGTCIfF10
UyReXa45oSNhaPS85IQcDfXp/km8jCy1FL0CtQuuVjaX9zJTF1JaU5qHE6J90IFQ
W6xcro+XzYXCUbhy8l5w4o9IRAPwl8vqdpcKW9XjGNbJg4Z7K5xrOI1/4gDE3Rh1
Codef09RJulmftM9OBLO
ûZh
--END PGP SIGNATURE--

--+Z7/5fzWRHDJ0o7Q--

--
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pierre-Elliott Bécue
Le #26130502
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTcMk8AAoJEHP5hLZrOe8xQd4QAJ0QCjhFZ5VCRHJy4IRiNNun
9Zr+JwTvATiCJn3FBTY2jtMXa+RWG3AlriC5xz33+bz44buZsQujweSlvVXokRiM
I1HvOM4VW6qNlhYNYNNQvO7VkLZxfWlz/JS02I1Icn4KGbmRcD5BdyrfwODJ8kXG
GJSjvAhXCQUzOBMRqkIdNJUt4CiSiThubrjDNUgDgQ69cKtk6j8FLXfx3BomP2/j
t5XK3V7Qk24X/SXJ21SHmLX3QSi0etK1t9l4jlecGMWH9OI1qNYtIS0Jgh1u8U4m
+kJbB9WdRW8CKw6T5VsIDJPIorrVhPnp4jzAYlStztBggZBOGOoWIUIecYsOng8t
V6MFtzku9fMp9d9ZKLsTGEFF09rThW4pQg+31erKfzeA/pFH18JmNQ5IHC7981s+
xrJBNEk0i8Un4DvIQjldn2vlE1iJELskmLHz21WJkvAauWYNCil8G1G7NrkpyM3T
d4AMbltd2kqhAgUKpAw2vD3qVjgJ0Kot0Lq1/AI32JBH1H3HfD1YvlVbW1399vvD
qWJKlLivJ93QsRKtmRHiHzHHzEWROlJzPQyv4Csd66auQn61AQSOoUKck/3DRi/0
ftRt0XMp+wruJbvBD7EegeExdYpZujpEVX1Kq/HOOb4cbLJau6XNIMNBidANx6O1
Tsynh+oAB3dFGdTU1SUl
=OCu1
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--

--
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 #26130642
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/
David Guyot
Le #26132052
--SCOJXUq1iwCn05li
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

Cordialement..
--
David Guyot
Administrateur système, réseau et télécommunications / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
Tel: +33 (0)3 29 30 47 85
Fax : +33 (0)3 29 31 31 31

--SCOJXUq1iwCn05li
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTcdWaAAoJEOdwVf06csTSGAwP/27j0i6AyYXC6+rHHSrMmoGl
AL/Sj/aW652EulVbf/R6Kb6Oka+aih0aGciU/5iq+MNQgj2Te9F/qYSfMpnXduei
LJAjNPPUrPHjmZr8TdVqAgVPeSfYhvQ/YtNbP320rkKu/4hVulDIUT3d8X63FBLc
TdYWsJwqGBEMM0a2+e7HyugqgIQWw3r/pYsOzEuu6sPeMTjOVKpRCE/DKoMKILrm
5ZcJ1IJBVoxhKUKiiOItSu8KqbAQ0MCy/CiRGQLhDoFCuRt0MErb8vRvkn8L7iny
tzCBMxCbaqtj9ZkMmclJ2zlih2Ms99/7LEWXkUu7+ZiXCs/YWT9cYwV+/t4HIYoV
yQeup/+BnpFvvf7MWQ6xDLnRzmhdNckIR5g2Fce5JwMF1bv91gi0y4oZceBcGEAz
ExXox6uSOOd4kLpf5OyMd+bHeBAk30cIomcF5Vjfh5Z7wFLQgVU7bpxfKJXOPEDf
aLThomaft9ZXx0AGGIqUJ/T30YPxeenA5HJqzodiKRjSJmYjC2LP2HDObHO4axRP
+y0FupND+tDpWv2KoQMELJ6CAmurRBsNhoG/Y0m7ArsEs8yvFtl8BGpwZbf+9fAE
jKmJxuFDie1Ib/pQeswy/V2ChZDcgi+bjEtPqXGcUSFBTxGmraaSLtpSC0H+7/cb
iwJ1cnBOd4Eq4cNxbzJm
=X6qV
-----END PGP SIGNATURE-----

--SCOJXUq1iwCn05li--

--
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/
Sylvain L. Sauvage
Le #26132152
Le mardi 13 mai 2014, 10:19:38 David Guyot a écrit :
[…]
Bonjour.



’jour,

[…] je continue de croire que le noyau devrait […]



Sauf que, comme dit plusieurs fois dans le fil, ça n’est pas
du ressort du noyau.

Le noyau ne fait que fournir une fonction, mount (man 2
mount), qui permet d’attacher des systèmes de fichiers à   l’arbre
des systèmes de fichier.
Cette fonction renvoie un code d’_erreur_ (voir la liste dans
la page de man précitée), pas un code d’_alerte_ (war ning). Ça
n’est pas son boulot de vérifier que le montage en cours à ©crase
ou masque un précédent montage. D’une part, comme te l’a dit
Jacques, il peut y avoir des cas où c’est utile. D’ autre part,
ça n’est tout simplement pas le niveau — la couche , l’étape —,
pour faire ça. Une fonction noyau, ça réussit ou ça échoue, il
n’y a pas d’intermédiaire.

Au niveau supérieur, c’est la commande mount. Donc ce se rait à
la commande mount (man 8 mount) de faire attention ou d’envoyer
un message d’alerte lors d’un masquage.
Donc si tu veux faire un rapport de bogue (plutôt du niveau
wishlist à mon avis), ce serait sur mount (paquet mount) qu’ il
faudrait le faire.

--
Sylvain Sauvage

--
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
Le #26132162
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/
Stéphane GARGOLY
Le #26132302
Bonjour à tous les utilisateurs et développeurs de Debian :

Le mardi 13 mai 2014 à 08:58, "Sylvain L. Sauvage" a écrit :
Sauf que, comme dit plusieurs fois dans le fil, ça n’est p as
du ressort du noyau.



D'où mon (léger) scepticisme implicitement exprimé en fin de mon précédent
courriel dans ce fil de discussion (par rapport à la demande de David).

Au niveau supérieur, c’est la commande mount. Donc ce sera it à
la commande mount (man 8 mount) de faire attention ou d’envoyer
un message d’alerte lors d’un masquage.
Donc si tu veux faire un rapport de bogue (plutôt du niveau
wishlist à mon avis), ce serait sur mount (paquet mount) qu’ il
faudrait le faire.



Cela me parait plus approprié, en effet...

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/
Bzzz
Le #26132972
On Tue, 13 May 2014 10:19:38 +0200
David Guyot
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



Il suffit d'avoir ne serais-ce qu'un quart de neurone
fonctionnel: on décolle rarement avec un planeur dont
on a pas encore monté les ailes…

--
Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un achet é !
Manon: Parfait je prend le gratuit !

--
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/
David Guyot
Le #26133092
--uX7BrQs69PbBafpd
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Le mardi 13 mai 2014 à 15:57:59 +0200, Bzzz a écrit:
On Tue, 13 May 2014 10:19:38 +0200
David Guyot
> 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

Il suffit d'avoir ne serais-ce qu'un quart de neurone
fonctionnel: on décolle rarement avec un planeur dont
on a pas encore monté les ailes…

--
Aria: On va à disneyland ensemble ? ya un ticket gratuit pour un ach eté !
Manon: Parfait je prend le gratuit !



Il faut d'abord penser à vérifier /etc/fstab ; malheureuseme nt, au moins
chez mon hébergeur, c'est leur installeur qui génère /etc/fs tab, donc on
n'a normalement pas besoin d'y retourner. Qui plus est, puisque c'est si
simple, on pourrait s'attendre à ce que le système avertisse de ce
problème, à mon humble avis ; j'ai déjà vu des log iciels lancer des
avertissements pour moins que ça, et, mount étant une commande es sentielle,
elle pourrait se permettre d'être plus bavarde que de simplement faire ce
qu'on lui dit sans avertir de problèmes potentiels.

Cordialement.
--
David Guyot
Administrateur système, réseau et télécommunications / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
Tel: +33 (0)3 29 30 47 85
Fax : +33 (0)3 29 31 31 31

--uX7BrQs69PbBafpd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTcjA5AAoJEOdwVf06csTSCpYP/0pE6eKwO+O2u0iR9T0i9KHe
KcOdhl9J5OdKHGquyiJg1Jzp/EuOO9ppxn1g6/f0dtxbep0UPF6HmhVFIDc9koaL
7MW2ebh4il/zPRkUzw8ITJY38vVu9W7a++ZybZO9BBwkap11Nd2IDByMExWMYpfo
hGK4oSqSLK+NeRHQVLiMufNvNvz8rbufUmAnlka/A+pE9OLbm668lU0DJxJr4B1e
GEEQ5mPsn8YgoYcLdmMsA7vg7C1leQS0S63onf4eBwgj4Yju9bXQatsyv519n4sf
gSUQN8dji7Um314iECqCLKnoOSufiBWibuUk+FGRJ26/LXQOVhyrRdKGCd8AjnUx
7eFflcHXBH7MisuJiGWSOblK7cjbe9iw4Ns+MBaUZOOxXX8MY3Pp2j2NQOMsz8Ns
6IUtAIyyomoNaWTpHI/Ur0B9Hiemt2atIOlac6fZy0te/WWL9wI4esvEsyJpDPwx
SQsZQvXzv9FW2D1z65bOPwJIQYDwWsLBl1MyexlsYBQoe0S/0A0AIT4S2ldiy6Ts
9AmBb4YOJlNx+XP/MME+Nrc3K0TefetTRIIolEGEMW2oJqkdgatxug2HpgSQkj2s
+h00k9qhJHDgYKV41xZOGy1nkobvGLC6tR1wfHQbmfTThl7tKAausiWcOVLfs4Iv
DLgJPtWSswJOKRg8L/1i
=GCPB
-----END PGP SIGNATURE-----

--uX7BrQs69PbBafpd--

--
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 #26133082
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/
Francois Lafont
Le #26133242
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$
Publicité
Poster une réponse
Anonyme