Dans un répertoire je dois indiquer un lien symbolique vers une
partition sans file system. Par exemple un lien symbolique vers
/dev/sdb2. Mais je voudrais plutôt utiliser un chemin avec un
UUID comme celui-là par exemple :
car les UUID sont constants. Seulement voilà, la partition n'a
pas de file system et, dans la pratique que j'ai eu jusque là,
c'est via le formatage en un fs que l'UUID est généré. Sans fs,
ma partition n'a pas d'UUID (le partitionnement a été fait avec
fdisk sous Ubuntu 14.04). Y a-t-il un moyen d'avoir un UUID
associé à une partition « brute » (ie sans fs), UUID qui devra
être reconnu par udev bien sûr ?
Et en fait, j'aurais exactement la même question dans le cas non
pas d'une partition mais d'un disque brute, genre /dev/sdb ? On
est d'accord que dans ce cas là je ne peux pas espérer avoir un
UUID associé au disque et que je suis obligé de passer par une
règle udev maison basée par exemple sur le serial number du disque
ou un truc dans le genre. Est-ce correct ?
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les disques au format gpt.
Pas seulement. Ils servent pour tout format exposant des UUID ou labels de partitions, comme GPT. Les noyaux 3.8 et plus synthétisent des UUID de partitions pour les disques au format MSDOS, on peut donc aussi utiliser PARTUUID.
mireero a écrit :
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les
disques au format gpt.
Pas seulement. Ils servent pour tout format exposant des UUID ou labels
de partitions, comme GPT. Les noyaux 3.8 et plus synthétisent des UUID
de partitions pour les disques au format MSDOS, on peut donc aussi
utiliser PARTUUID.
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les disques au format gpt.
Pas seulement. Ils servent pour tout format exposant des UUID ou labels de partitions, comme GPT. Les noyaux 3.8 et plus synthétisent des UUID de partitions pour les disques au format MSDOS, on peut donc aussi utiliser PARTUUID.
mireero
On 03/25/2015 08:20 PM, Francois Lafont wrote:
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié à systemd.
Je pense que cela n'a rien à voir avec systemd, qui s'occupe de gérer les services (dont udev fait bien sûr parti).
L'introduction de cette page https://wiki.archlinux.org/index.php/fstab semble indiquer que ça serait pourtant bien lié :
« The /etc/fstab file can be used to define how disk partitions, various other block devices, or remote filesystems should be mounted into the filesystem. Each filesystem is described in a separate line.
**These definitions will be converted into systemd mount units dynamically at boot** »
Bon, ceci étant, ce n'est pas une preuve, on est d'accord. Perso, j'ai un peu la flemme et surtout pas le temps d'approfondir cette question.
Disons que c'est un peu satellite à la question ici (si j'ai compris, systemd lit fstab et crée un jeu de dépendances/parallélisme pour lancer les commandes mount de façon efficace).
Ok, pour UUID. Pour ma part, je parlais de PARTUUID et de PARTLABEL qui eux ne fonctionnent pas sur Ubuntu 14.04 (j'ai testé).
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ni dans le man de Ubuntu 14.04, or Ubuntu 14.04 et Wheezy ne se basent pas sur systemd, Jessie si. Bon ok, ça ne prouve rien. :p
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les disques au format gpt.
Il y a 2 façons d'identifier un disque (ou plus généralement un périphérique), grâce à une propriété inhérente au disque (qui nécessite donc un accès au disque, en amont, c'est udev qui s'en occupe), donc par exemple un uuid, un label, ou n'importe quelle propriété ou mélange de propriété que tu peux obtenir facilement grâce à udevadm (voir plus bas). La 2ème façon, c'est par "path", sur quel port (pci, usb...) est branché ton périphérique.
Comme j'ai indiqué, je souhaite que le lien symbolique soit constant même si le disque change d'emplacement.
C'est vrai que je suis allé un peu vite, le by-id (que te conseille Lucas dans le message suivant) est formé un peu différemment. La règle dans /lib/udev/rules.d/60-persistent-storage.rules (dans debian) forme des liens du style: ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}" pour un disque et pour une partition: ENV{DEVTYPE}=="partition", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
Enfin, c'est l'idée, ça dépend du type de disque.
En passant, même sans système de fichier le périphérique est accessible "by-path". Je répète mon dernier message, sur mon ordi j'ai: /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0' -> `../../sda
Ok, mais donc le chemin du symlink dépend de l'emplacement du disque si j'ai bien suivi, non ?
Oui, là on est "by-path".
Merci pour toutes ces commandes. J'en connaissais certaines mais pas toutes. Je ne suis pas très calé en udev. Mais j'ai déjà réussi à faire des règles udev basées sur S/N d'un disque. Et c'est, à ma connaissance, le seul moyen que j'ai trouvé pour avoir un symlink associé au disque (sans rien supposer au niveau de son partitionnement et des fs qui s'y trouvent, s'il y en cas) et constant même en cas de changement d'emplacement du disque.
Le seul moyen que j'ai trouvé donc, à moins que les symlinks /dev/disk/by-{id,path} aient ces caractéristiques là mais j'ai des doutes et je n'ai pas eu le temps de tester.
C'est ça, soit tu utilises la règle livrée avec le système, par exemple "by-id", soit tu crées la tienne.
Ah ok, merci du conseil. Donc par exemple, si je veux repartir de zéro sur un disque avec du MSDOS, je dois faire par exemple :
dd if=/dev/zero of=/dev/sdb bs 48K count=1
Ça suffira ?
Plus que suffisant mais vu que tu va recréer une table de partition (par exemple dos avec fdisk ou gpt avec gdisk), cette dernière écrasera l'ancienne (enfin tu la supprimeras directement grâce au programme ?disk).
Ah, ben j'ai mal compris ce que voulais dire Pascal alors parce que, justement, j'avais compris que certains outils de partitionnement non « gtp aware » pouvaient laisser la « signature GPT » (j'ignore ce que c'est exactement) lorsqu'ils recréaient la table de partition MSDOS sur un disque initialement partitionné en GPT et que du coup ça pouvait poser des problèmes avec les outils de partitionnement des installateurs Debian.
Dac, c'est moi qui avait mal compris :) Disons que si tu effaces juste les 512 premiers octets puis que tu regardes ton disque dans fdisk, il le verra vierge. Même s'il était préalablement en gpt (enfin, sauf si fdisk cherche à faire plus que son travail). Par contre, si tu l'ouvres dans gdisk, il pourra encore lire des informations sur le partitionnement gpt non totalement effacé (d'autant qu'il y a un backup à la fin du disque). Donc si l'installateur cherche une signature gpt, c'est vrai qu'il vaut mieux effacer quelques Mo (et aussi quelques Mo à la fin du disque pour faire bonne mesure).
Et pour info, le mbr se situe entre les adresses 0 et 445 inclus, la table des partitions de 446 à 511, donc pas besoin d'effacer 2Mo:
# dd if=/dev/zero of=/dev/sdb bsD6 count=1
Ah donc, c'est fameuse signature GPT à virer se trouve dans le MBR, c'est ça ?
Non, non, désolé je t'ai induis en erreur!
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Que j'utilise une table de partition GPT ou MSDOS, elle se trouve toujours de 446 à 511 ?
Non, juste dos. Le partitionnement gpt est plus gourmand (d'autant qu'il autorise au moins une centaine de partitions (128 octets par entrée et un tas d'en-têtes) et prend plus de place, d'où sans doute ta commande où tu effaçais les 2 premiers Mo.
(Dans le cas d'un mbr/dos, on a 16 octets par entrée, 64 pour les 4 partitions, les 2 derniers octets étant un code pour dire si on doit bien s'amorcer à partir d'ici, ça y est, je m'égare encore, temps de dormir...)
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Oui tout à fait mais ici, à moins que j'ai mal compris ce que disait Pascal, on se plaçait dans le cas où un disque était partitionné avec un outil non « gtp aware » alors que celui-ci était anciennement partitionné en GPT.
Je vois, en tout cas je ne peux que te conseiller gdisk (mais même gparted peut sans problème te détruire une table de partitions, quelle soit gpt, dos ou autre).
Merci de ton aide.
Il semble que tu ais trouvé ton bonheur avec "by-id", tant mieux!
Bonne nuit à tous...
-- mireero
On 03/25/2015 08:20 PM, Francois Lafont wrote:
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié
à systemd.
Je pense que cela n'a rien à voir avec systemd, qui s'occupe de gérer les services (dont udev fait bien sûr parti).
L'introduction de cette page https://wiki.archlinux.org/index.php/fstab
semble indiquer que ça serait pourtant bien lié :
« The /etc/fstab file can be used to define how disk partitions, various other
block devices, or remote filesystems should be mounted into the filesystem.
Each filesystem is described in a separate line.
**These definitions will be converted into systemd mount units dynamically at boot** »
Bon, ceci étant, ce n'est pas une preuve, on est d'accord.
Perso, j'ai un peu la flemme et surtout pas le temps d'approfondir
cette question.
Disons que c'est un peu satellite à la question ici (si j'ai compris,
systemd lit fstab et crée un jeu de dépendances/parallélisme pour lancer
les commandes mount de façon efficace).
Ok, pour UUID. Pour ma part, je parlais de PARTUUID et de PARTLABEL qui eux
ne fonctionnent pas sur Ubuntu 14.04 (j'ai testé).
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ni dans le man de Ubuntu 14.04, or Ubuntu 14.04 et Wheezy ne se basent pas
sur systemd, Jessie si. Bon ok, ça ne prouve rien. :p
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les
disques au format gpt.
Il y a 2 façons d'identifier un disque (ou plus généralement un périphérique), grâce à une propriété inhérente au disque (qui nécessite donc un accès au disque, en amont, c'est udev qui s'en occupe), donc par exemple un uuid, un label, ou n'importe quelle propriété ou mélange de propriété que tu peux obtenir facilement grâce à udevadm (voir plus bas).
La 2ème façon, c'est par "path", sur quel port (pci, usb...) est branché ton périphérique.
Comme j'ai indiqué, je souhaite que le lien symbolique soit constant même
si le disque change d'emplacement.
C'est vrai que je suis allé un peu vite, le by-id (que te conseille
Lucas dans le message suivant) est formé un peu différemment. La règle
dans /lib/udev/rules.d/60-persistent-storage.rules (dans debian) forme
des liens du style:
ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}=="?*",
SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
pour un disque et pour une partition:
ENV{DEVTYPE}=="partition", ENV{ID_SERIAL}=="?*",
SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
Enfin, c'est l'idée, ça dépend du type de disque.
En passant, même sans système de fichier le périphérique est accessible "by-path". Je répète mon dernier message, sur mon ordi j'ai:
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0' -> `../../sda
Ok, mais donc le chemin du symlink dépend de l'emplacement
du disque si j'ai bien suivi, non ?
Oui, là on est "by-path".
Merci pour toutes ces commandes. J'en connaissais certaines
mais pas toutes. Je ne suis pas très calé en udev. Mais j'ai
déjà réussi à faire des règles udev basées sur S/N d'un disque.
Et c'est, à ma connaissance, le seul moyen que j'ai trouvé
pour avoir un symlink associé au disque (sans rien supposer au
niveau de son partitionnement et des fs qui s'y trouvent, s'il
y en cas) et constant même en cas de changement d'emplacement du
disque.
Le seul moyen que j'ai trouvé donc, à moins que les symlinks
/dev/disk/by-{id,path} aient ces caractéristiques là mais j'ai des
doutes et je n'ai pas eu le temps de tester.
C'est ça, soit tu utilises la règle livrée avec le système, par exemple
"by-id", soit tu crées la tienne.
Ah ok, merci du conseil. Donc par exemple, si je veux repartir de zéro
sur un disque avec du MSDOS, je dois faire par exemple :
dd if=/dev/zero of=/dev/sdb bs 48K count=1
Ça suffira ?
Plus que suffisant mais vu que tu va recréer une table de partition (par exemple dos avec fdisk ou gpt avec gdisk), cette dernière écrasera l'ancienne (enfin tu la supprimeras directement grâce au programme ?disk).
Ah, ben j'ai mal compris ce que voulais dire Pascal alors parce
que, justement, j'avais compris que certains outils de partitionnement
non « gtp aware » pouvaient laisser la « signature GPT » (j'ignore ce
que c'est exactement) lorsqu'ils recréaient la table de partition MSDOS
sur un disque initialement partitionné en GPT et que du coup ça pouvait
poser des problèmes avec les outils de partitionnement des installateurs
Debian.
Dac, c'est moi qui avait mal compris :)
Disons que si tu effaces juste les 512 premiers octets puis que tu
regardes ton disque dans fdisk, il le verra vierge.
Même s'il était préalablement en gpt (enfin, sauf si fdisk cherche à
faire plus que son travail).
Par contre, si tu l'ouvres dans gdisk, il pourra encore lire des
informations sur le partitionnement gpt non totalement effacé (d'autant
qu'il y a un backup à la fin du disque).
Donc si l'installateur cherche une signature gpt, c'est vrai qu'il vaut
mieux effacer quelques Mo (et aussi quelques Mo à la fin du disque pour
faire bonne mesure).
Et pour info, le mbr se situe entre les adresses 0 et 445 inclus, la table des partitions de 446 à 511, donc pas besoin d'effacer 2Mo:
# dd if=/dev/zero of=/dev/sdb bsD6 count=1
Ah donc, c'est fameuse signature GPT à virer se trouve dans le MBR,
c'est ça ?
Non, non, désolé je t'ai induis en erreur!
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Que j'utilise une table de partition GPT ou MSDOS, elle se trouve toujours
de 446 à 511 ?
Non, juste dos. Le partitionnement gpt est plus gourmand (d'autant qu'il
autorise au moins une centaine de partitions (128 octets par entrée et
un tas d'en-têtes) et prend plus de place, d'où sans doute ta commande
où tu effaçais les 2 premiers Mo.
(Dans le cas d'un mbr/dos, on a 16 octets par entrée, 64 pour les 4
partitions, les 2 derniers octets étant un code pour dire si on doit
bien s'amorcer à partir d'ici, ça y est, je m'égare encore, temps de
dormir...)
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Oui tout à fait mais ici, à moins que j'ai mal compris ce que disait Pascal,
on se plaçait dans le cas où un disque était partitionné avec un outil non
« gtp aware » alors que celui-ci était anciennement partitionné en GPT.
Je vois, en tout cas je ne peux que te conseiller gdisk (mais même
gparted peut sans problème te détruire une table de partitions, quelle
soit gpt, dos ou autre).
Merci de ton aide.
Il semble que tu ais trouvé ton bonheur avec "by-id", tant mieux!
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié à systemd.
Je pense que cela n'a rien à voir avec systemd, qui s'occupe de gérer les services (dont udev fait bien sûr parti).
L'introduction de cette page https://wiki.archlinux.org/index.php/fstab semble indiquer que ça serait pourtant bien lié :
« The /etc/fstab file can be used to define how disk partitions, various other block devices, or remote filesystems should be mounted into the filesystem. Each filesystem is described in a separate line.
**These definitions will be converted into systemd mount units dynamically at boot** »
Bon, ceci étant, ce n'est pas une preuve, on est d'accord. Perso, j'ai un peu la flemme et surtout pas le temps d'approfondir cette question.
Disons que c'est un peu satellite à la question ici (si j'ai compris, systemd lit fstab et crée un jeu de dépendances/parallélisme pour lancer les commandes mount de façon efficace).
Ok, pour UUID. Pour ma part, je parlais de PARTUUID et de PARTLABEL qui eux ne fonctionnent pas sur Ubuntu 14.04 (j'ai testé).
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ni dans le man de Ubuntu 14.04, or Ubuntu 14.04 et Wheezy ne se basent pas sur systemd, Jessie si. Bon ok, ça ne prouve rien. :p
En fait, si je dis pas de bêtise, PARTUUID et PARTLABEL servent pour les disques au format gpt.
Il y a 2 façons d'identifier un disque (ou plus généralement un périphérique), grâce à une propriété inhérente au disque (qui nécessite donc un accès au disque, en amont, c'est udev qui s'en occupe), donc par exemple un uuid, un label, ou n'importe quelle propriété ou mélange de propriété que tu peux obtenir facilement grâce à udevadm (voir plus bas). La 2ème façon, c'est par "path", sur quel port (pci, usb...) est branché ton périphérique.
Comme j'ai indiqué, je souhaite que le lien symbolique soit constant même si le disque change d'emplacement.
C'est vrai que je suis allé un peu vite, le by-id (que te conseille Lucas dans le message suivant) est formé un peu différemment. La règle dans /lib/udev/rules.d/60-persistent-storage.rules (dans debian) forme des liens du style: ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}" pour un disque et pour une partition: ENV{DEVTYPE}=="partition", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"
Enfin, c'est l'idée, ça dépend du type de disque.
En passant, même sans système de fichier le périphérique est accessible "by-path". Je répète mon dernier message, sur mon ordi j'ai: /dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0' -> `../../sda
Ok, mais donc le chemin du symlink dépend de l'emplacement du disque si j'ai bien suivi, non ?
Oui, là on est "by-path".
Merci pour toutes ces commandes. J'en connaissais certaines mais pas toutes. Je ne suis pas très calé en udev. Mais j'ai déjà réussi à faire des règles udev basées sur S/N d'un disque. Et c'est, à ma connaissance, le seul moyen que j'ai trouvé pour avoir un symlink associé au disque (sans rien supposer au niveau de son partitionnement et des fs qui s'y trouvent, s'il y en cas) et constant même en cas de changement d'emplacement du disque.
Le seul moyen que j'ai trouvé donc, à moins que les symlinks /dev/disk/by-{id,path} aient ces caractéristiques là mais j'ai des doutes et je n'ai pas eu le temps de tester.
C'est ça, soit tu utilises la règle livrée avec le système, par exemple "by-id", soit tu crées la tienne.
Ah ok, merci du conseil. Donc par exemple, si je veux repartir de zéro sur un disque avec du MSDOS, je dois faire par exemple :
dd if=/dev/zero of=/dev/sdb bs 48K count=1
Ça suffira ?
Plus que suffisant mais vu que tu va recréer une table de partition (par exemple dos avec fdisk ou gpt avec gdisk), cette dernière écrasera l'ancienne (enfin tu la supprimeras directement grâce au programme ?disk).
Ah, ben j'ai mal compris ce que voulais dire Pascal alors parce que, justement, j'avais compris que certains outils de partitionnement non « gtp aware » pouvaient laisser la « signature GPT » (j'ignore ce que c'est exactement) lorsqu'ils recréaient la table de partition MSDOS sur un disque initialement partitionné en GPT et que du coup ça pouvait poser des problèmes avec les outils de partitionnement des installateurs Debian.
Dac, c'est moi qui avait mal compris :) Disons que si tu effaces juste les 512 premiers octets puis que tu regardes ton disque dans fdisk, il le verra vierge. Même s'il était préalablement en gpt (enfin, sauf si fdisk cherche à faire plus que son travail). Par contre, si tu l'ouvres dans gdisk, il pourra encore lire des informations sur le partitionnement gpt non totalement effacé (d'autant qu'il y a un backup à la fin du disque). Donc si l'installateur cherche une signature gpt, c'est vrai qu'il vaut mieux effacer quelques Mo (et aussi quelques Mo à la fin du disque pour faire bonne mesure).
Et pour info, le mbr se situe entre les adresses 0 et 445 inclus, la table des partitions de 446 à 511, donc pas besoin d'effacer 2Mo:
# dd if=/dev/zero of=/dev/sdb bsD6 count=1
Ah donc, c'est fameuse signature GPT à virer se trouve dans le MBR, c'est ça ?
Non, non, désolé je t'ai induis en erreur!
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Que j'utilise une table de partition GPT ou MSDOS, elle se trouve toujours de 446 à 511 ?
Non, juste dos. Le partitionnement gpt est plus gourmand (d'autant qu'il autorise au moins une centaine de partitions (128 octets par entrée et un tas d'en-têtes) et prend plus de place, d'où sans doute ta commande où tu effaçais les 2 premiers Mo.
(Dans le cas d'un mbr/dos, on a 16 octets par entrée, 64 pour les 4 partitions, les 2 derniers octets étant un code pour dire si on doit bien s'amorcer à partir d'ici, ça y est, je m'égare encore, temps de dormir...)
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Oui tout à fait mais ici, à moins que j'ai mal compris ce que disait Pascal, on se plaçait dans le cas où un disque était partitionné avec un outil non « gtp aware » alors que celui-ci était anciennement partitionné en GPT.
Je vois, en tout cas je ne peux que te conseiller gdisk (mais même gparted peut sans problème te détruire une table de partitions, quelle soit gpt, dos ou autre).
Merci de ton aide.
Il semble que tu ais trouvé ton bonheur avec "by-id", tant mieux!
Bonne nuit à tous...
-- mireero
Nicolas George
Pascal Hambourg , dans le message <mevetc$223r$, a écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
Pascal Hambourg , dans le message <mevetc$223r$1@saria.nerim.net>, a
écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à
résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir
ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le
cas du changement intempestif de nom au gré de la détection asynchrone du
matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on
peut bien éditer fstab par la même occasion.
Pascal Hambourg , dans le message <mevetc$223r$, a écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
Pascal Hambourg
Nicolas George a écrit :
Pascal Hambourg , dans le message <mevetc$223r$, a écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
Le changement de nom de périphérique est le problème principal qu'il faut impérativement prendre en compte car il peut survenir indépendamment de toute action de l'administrateur ou de l'utilisateur de la machine. Mais si la solution pouvait prendre en compte les autres situations, cela simplifierait la vie de l'administrateur. Il n'y a pas forcément que fstab à éditer en cas de changement de disque : par exemple l'emplacement de GRUB dans debconf, du swap pour l'hibernation dans l'initramfs...
Nicolas George a écrit :
Pascal Hambourg , dans le message <mevetc$223r$1@saria.nerim.net>, a
écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à
résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir
ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le
cas du changement intempestif de nom au gré de la détection asynchrone du
matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on
peut bien éditer fstab par la même occasion.
Le changement de nom de périphérique est le problème principal qu'il
faut impérativement prendre en compte car il peut survenir
indépendamment de toute action de l'administrateur ou de l'utilisateur
de la machine. Mais si la solution pouvait prendre en compte les autres
situations, cela simplifierait la vie de l'administrateur. Il n'y a pas
forcément que fstab à éditer en cas de changement de disque : par
exemple l'emplacement de GRUB dans debconf, du swap pour l'hibernation
dans l'initramfs...
Pascal Hambourg , dans le message <mevetc$223r$, a écrit :
Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
Le changement de nom de périphérique est le problème principal qu'il faut impérativement prendre en compte car il peut survenir indépendamment de toute action de l'administrateur ou de l'utilisateur de la machine. Mais si la solution pouvait prendre en compte les autres situations, cela simplifierait la vie de l'administrateur. Il n'y a pas forcément que fstab à éditer en cas de changement de disque : par exemple l'emplacement de GRUB dans debconf, du swap pour l'hibernation dans l'initramfs...
Sergio
Le 26/03/2015 09:42, Nicolas George a écrit :
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
J'ai longtemps eu une détection asynchrone des lecteurs de cartes (SD, MMC etc.) qui me plaçait mon disque principal en /dev/sde au lieu de sa place habituelle (/dev/sda). Ça ne gênait en rien le déroulement des opérations grâce aux UUID...
Ça s'est calmé depuis, mais ça peut revenir...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 26/03/2015 09:42, Nicolas George a écrit :
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à
résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir
ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le
cas du changement intempestif de nom au gré de la détection asynchrone du
matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on
peut bien éditer fstab par la même occasion.
J'ai longtemps eu une détection asynchrone des lecteurs de cartes (SD, MMC etc.) qui me plaçait mon disque principal en /dev/sde au
lieu de sa place habituelle (/dev/sda). Ça ne gênait en rien le déroulement des opérations grâce aux UUID...
Ça s'est calmé depuis, mais ça peut revenir...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Concrètement, il faudrait commencer par se mettre d'accord sur le problème à résoudre, parce que chacun a sa propre vision de ce à quoi peuvent servir ces labels et UUID.
De mon point de vue, le seul problème qui ait BESOIN d'être résolu, c'est le cas du changement intempestif de nom au gré de la détection asynchrone du matériel. Dans tous les autres cas, si on bricole à déplacer ses disques, on peut bien éditer fstab par la même occasion.
J'ai longtemps eu une détection asynchrone des lecteurs de cartes (SD, MMC etc.) qui me plaçait mon disque principal en /dev/sde au lieu de sa place habituelle (/dev/sda). Ça ne gênait en rien le déroulement des opérations grâce aux UUID...
Ça s'est calmé depuis, mais ça peut revenir...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Nicolas George
Pascal Hambourg , dans le message <mf0hc6$2d4s$, a écrit :
Mais si la solution pouvait prendre en compte les autres situations, cela simplifierait la vie de l'administrateur.
Oui, mais du coup, les choses qui se contentent de simplifier la vie de l'administrateur, par opposition à celles qui sont nécessaire pour un démarrage fiable, il y a beaucoup moins d'urgence, donc on peut tranquillement attendre que le reste du monde adopte des standards un peu moins pourris, comme GPT.
Pascal Hambourg , dans le message <mf0hc6$2d4s$1@saria.nerim.net>, a
écrit :
Mais si la solution pouvait prendre en compte les autres
situations, cela simplifierait la vie de l'administrateur.
Oui, mais du coup, les choses qui se contentent de simplifier la vie de
l'administrateur, par opposition à celles qui sont nécessaire pour un
démarrage fiable, il y a beaucoup moins d'urgence, donc on peut
tranquillement attendre que le reste du monde adopte des standards un peu
moins pourris, comme GPT.
Pascal Hambourg , dans le message <mf0hc6$2d4s$, a écrit :
Mais si la solution pouvait prendre en compte les autres situations, cela simplifierait la vie de l'administrateur.
Oui, mais du coup, les choses qui se contentent de simplifier la vie de l'administrateur, par opposition à celles qui sont nécessaire pour un démarrage fiable, il y a beaucoup moins d'urgence, donc on peut tranquillement attendre que le reste du monde adopte des standards un peu moins pourris, comme GPT.
