Pascal Hambourg , dans le message <mepq68$8ic$, a
écrit :Les labels sont également stockés dans le filesystem lui-même.
C'est pourquoi je trouve personnellement que la mode des UUID et des labels
est assez idiote pour les disques système.
Pourquoi ?
Parce que les UUID et les labels sont stockés dans le bouzin qu'ils sont
censés identifier, comme je viens de le souligner.
Si le but reste d'identifier le contenu (le système de fichiers) plus
que le contenant (la partition), alors l'UUID ou le label me semble
approprié.
Peut-être, mais ça ne marche pas, parce que tu dois forcément faire des
hypothèses sur le contenu, alors que le principe est d'avoir une séparation
en couches successives.
Dit autrement : tu ne peux pas connaître l'UUID ou le label d'un volume à
moins de déjà savoir lire ce volume.
Une conséquence plus directement pratique est qu'un même contenu pourrait
être reconnu comme plusieurs filesystems différents et avoir des labels et
UUID différents selon celui qui est reconnu en premier.
C'est un peu la même erreur que font ceux qui s'extasient devant l'idée
d'utiliser file/libmagic pour savoir quoi faire d'un fichier plutôt que son
extension.
Pascal Hambourg , dans le message <mepq68$8ic$2@saria.nerim.net>, a
écrit :
Les labels sont également stockés dans le filesystem lui-même.
C'est pourquoi je trouve personnellement que la mode des UUID et des labels
est assez idiote pour les disques système.
Pourquoi ?
Parce que les UUID et les labels sont stockés dans le bouzin qu'ils sont
censés identifier, comme je viens de le souligner.
Si le but reste d'identifier le contenu (le système de fichiers) plus
que le contenant (la partition), alors l'UUID ou le label me semble
approprié.
Peut-être, mais ça ne marche pas, parce que tu dois forcément faire des
hypothèses sur le contenu, alors que le principe est d'avoir une séparation
en couches successives.
Dit autrement : tu ne peux pas connaître l'UUID ou le label d'un volume à
moins de déjà savoir lire ce volume.
Une conséquence plus directement pratique est qu'un même contenu pourrait
être reconnu comme plusieurs filesystems différents et avoir des labels et
UUID différents selon celui qui est reconnu en premier.
C'est un peu la même erreur que font ceux qui s'extasient devant l'idée
d'utiliser file/libmagic pour savoir quoi faire d'un fichier plutôt que son
extension.
Pascal Hambourg , dans le message <mepq68$8ic$, a
écrit :Les labels sont également stockés dans le filesystem lui-même.
C'est pourquoi je trouve personnellement que la mode des UUID et des labels
est assez idiote pour les disques système.
Pourquoi ?
Parce que les UUID et les labels sont stockés dans le bouzin qu'ils sont
censés identifier, comme je viens de le souligner.
Si le but reste d'identifier le contenu (le système de fichiers) plus
que le contenant (la partition), alors l'UUID ou le label me semble
approprié.
Peut-être, mais ça ne marche pas, parce que tu dois forcément faire des
hypothèses sur le contenu, alors que le principe est d'avoir une séparation
en couches successives.
Dit autrement : tu ne peux pas connaître l'UUID ou le label d'un volume à
moins de déjà savoir lire ce volume.
Une conséquence plus directement pratique est qu'un même contenu pourrait
être reconnu comme plusieurs filesystems différents et avoir des labels et
UUID différents selon celui qui est reconnu en premier.
C'est un peu la même erreur que font ceux qui s'extasient devant l'idée
d'utiliser file/libmagic pour savoir quoi faire d'un fichier plutôt que son
extension.
C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Pas besoin de savoir lire tout le volume mais juste ce qui est
nécessaire pour déterminer son UUID, comme le superbloc ou équivalent.
Je suppose que c'est ce font libblkid, libmagic et autres.
C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Pas besoin de savoir lire tout le volume mais juste ce qui est
nécessaire pour déterminer son UUID, comme le superbloc ou équivalent.
Je suppose que c'est ce font libblkid, libmagic et autres.
C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Pas besoin de savoir lire tout le volume mais juste ce qui est
nécessaire pour déterminer son UUID, comme le superbloc ou équivalent.
Je suppose que c'est ce font libblkid, libmagic et autres.
Du coup, j'ai voulu tester un partitionnement « GPT » avec gdisk
(dont l'utilisation est très similaire à fdisk) et l'idée qu'il
y ait un UUID pour les partitions est assez sympa je trouve.
C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
begin{petite-remarque-en-passant}
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
J'aurais une dernière question : perso, je partitionne avec fdisk depuis
« toujours ». Est-ce que Linux gère bien les partitions GPT ?
Oui.
Pas de problème particulier ?
Le site de l'auteur de gdisk mentionne des limitations du noyau Linux et
de GRUB avec un MBR hybride, mais c'est non standard. Avec un disque au
format GPT pur, je n'ai jamais eu de problème.
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
Il est aussi un peu plus compliqué de cloner proprement un disque GPT
vers un disque de taille différente.Pour moi, GPT ça évoque des trucs inconnus et un peu troubles
comme "UEFI" etc. autrement dit pas des trucs qui font peur. ;)
En ce qui concerne GNU/Linux, UEFI et GPT sont indépendants. Si
l'amorçage se fait en mode BIOS/CSM/legacy avec GRUB sur un disque au
format GPT, il faut juste penser à créer une partition de type "BIOS
boot" (bios_grub) pour GRUB. Les problèmes seraient plutôt du côté de
Windows qui n'accepte de s'installer sur un disque GPT qu'en UEFI.
Du coup, j'ai voulu tester un partitionnement « GPT » avec gdisk
(dont l'utilisation est très similaire à fdisk) et l'idée qu'il
y ait un UUID pour les partitions est assez sympa je trouve.
C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
begin{petite-remarque-en-passant}
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
J'aurais une dernière question : perso, je partitionne avec fdisk depuis
« toujours ». Est-ce que Linux gère bien les partitions GPT ?
Oui.
Pas de problème particulier ?
Le site de l'auteur de gdisk mentionne des limitations du noyau Linux et
de GRUB avec un MBR hybride, mais c'est non standard. Avec un disque au
format GPT pur, je n'ai jamais eu de problème.
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
Il est aussi un peu plus compliqué de cloner proprement un disque GPT
vers un disque de taille différente.
Pour moi, GPT ça évoque des trucs inconnus et un peu troubles
comme "UEFI" etc. autrement dit pas des trucs qui font peur. ;)
En ce qui concerne GNU/Linux, UEFI et GPT sont indépendants. Si
l'amorçage se fait en mode BIOS/CSM/legacy avec GRUB sur un disque au
format GPT, il faut juste penser à créer une partition de type "BIOS
boot" (bios_grub) pour GRUB. Les problèmes seraient plutôt du côté de
Windows qui n'accepte de s'installer sur un disque GPT qu'en UEFI.
Du coup, j'ai voulu tester un partitionnement « GPT » avec gdisk
(dont l'utilisation est très similaire à fdisk) et l'idée qu'il
y ait un UUID pour les partitions est assez sympa je trouve.
C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
begin{petite-remarque-en-passant}
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
J'aurais une dernière question : perso, je partitionne avec fdisk depuis
« toujours ». Est-ce que Linux gère bien les partitions GPT ?
Oui.
Pas de problème particulier ?
Le site de l'auteur de gdisk mentionne des limitations du noyau Linux et
de GRUB avec un MBR hybride, mais c'est non standard. Avec un disque au
format GPT pur, je n'ai jamais eu de problème.
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
Il est aussi un peu plus compliqué de cloner proprement un disque GPT
vers un disque de taille différente.Pour moi, GPT ça évoque des trucs inconnus et un peu troubles
comme "UEFI" etc. autrement dit pas des trucs qui font peur. ;)
En ce qui concerne GNU/Linux, UEFI et GPT sont indépendants. Si
l'amorçage se fait en mode BIOS/CSM/legacy avec GRUB sur un disque au
format GPT, il faut juste penser à créer une partition de type "BIOS
boot" (bios_grub) pour GRUB. Les problèmes seraient plutôt du côté de
Windows qui n'accepte de s'installer sur un disque GPT qu'en UEFI.
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans
le 2ème cas (wheezy).
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans
le 2ème cas (wheezy).
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans
le 2ème cas (wheezy).
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié
à systemd.
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Moi non plus. ;) Je pense que c'est PARTUUID et PARTLABEL qu'il faut
utiliser (mais je n'ai pas testé donc).
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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 ?
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié
à systemd.
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Moi non plus. ;) Je pense que c'est PARTUUID et PARTLABEL qu'il faut
utiliser (mais je n'ai pas testé donc).
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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 ?
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :
En supposant qu'on mette un fs ensuite dans cette partition, d'après
ce que j'ai vu sur le web, il apparaissait sur certains sites qu'on pouvait
monter le fs dans fstab via des lignes comme :
# On utilise l'UUID de la partition GPT.
PARTUUID=.... etc.
# Ici on utilise le label de la partition GPT.
PARTLABEL=... etc.
Seulement ça ne marche pas sur une Ubuntu 14.04 (machine sur laquelle
j'ai fait mes essais) car, d'après ce que j'ai pu comprendre, ça ne
fonctionne que sur un Linux qui utilise systemd ce qui n'est pas le cas
de Ubuntu 14.04.
Je ne sais pas si c'est lié à systemd,
Je ne suis pas sûr de moi non plus mais il me semble que c'est bien lié
à systemd.
mais la page de manuel d'une
version assez récente de la commande 'mount' (comme celle de Debian
8/Jessie) indique que les UUID et labels de partition sont aussi
supportés. Par contre il n'est pas clair si dans ce cas la syntaxe reste
UUID= et LABEL= ou devient PARTUUID= et PARTLABEL=. Je n'ai pas
d'installation de Debian Jessie pour tester.
Moi non plus. ;) Je pense que c'est PARTUUID et PARTLABEL qu'il faut
utiliser (mais je n'ai pas testé donc).
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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 ?
Francois, tu n'as pas lu mon dernier message?
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).
Un simple tour dans la page de manuel de fstab:
*Debian 8*:
Instead of giving the device explicitly, one may indicate the filesystem that is to be mounted by its UUID or LABEL (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot' or
`UUID>6be9de-8139-11d1-9106-a43f08d823a6'.
It's also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).
*Debian 7*:
Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by
its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g.,
`LABEL=Boot' or `UUID>6be9de-8139-11d1-9106-a43f08d823a6'. This will make the system more robust: adding or
removing a SCSI disk changes the disk device name but not the filesystem volume label.
Comme je te l'ai déjà signalé, la syntaxe "UUID=<uuid>" fonctionne dans tous les cas et je ne vois pas de rapport avec systemd.
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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.
Maintenant, t'as le choix:
- Par exemple tu peux faire en sorte que toutes les clefs usb que tu branches sur tel port usb soient montées dans /media/MonDossierPortUsb (donc on utilise by-path).
- Ou chaque clef usb doit être montée dans son dossier spécifique quelque soit le port sur lequel tu les branches (là, on est by-id, label ou propriété inhérente à chaque clef).
Bref, en anglais on dirait que c'est une question de "policy" (j'arrive pas à traduire ce mot),
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
Petite info pour faciliter la recherche de propriétés disons de /dev/sda:
~ # udevadm info -a -n sda
[...]
looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda':
[...]
ATTR{size}=="500118192"
[...]
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0':
[...]
ATTRS{model}=="Samsung SSD 840 "
[...]
Ici on voit par exemple que j'ai un disque Samsung de 500118192 blocks et j'ai son chemin. Comme je ne le change jamais de branchement, si je voulais modifier son comportement lorsqu'il est découvert par le kernel -> udev ou exécuter un programme arbitraire, j'utiliserais son chemin d'accès (by-path).
Un exemple utile, j'ai un disque externe 1Go formaté en ntfs, quand je le branche avant de démarrer, aucun problème, sa ligne dans fstab fait son travail mais si je le branche à chaud ntfs-3g se plaint de ne pas avoir été compilé avec telle ou telle option je sais plus, en tout cas je suis obligé de le monter à la main en root. Donc j'ai ajouté une règle udev qui se base sur sa taille (pourquoi pas, j'ai pas d'autre disque de cette taille), la voici:
ACTION=="add", SUBSYSTEM=="block", ATTR{size}=="1367464844", RUN+="/usr/bin/MonMountDisk-Backup.sh"
J'aurais pu rajouter un SYMLINK+="mes_disques/disk1G" pour voir apparaître le disque dans /dev/mes_disques/disk1G.
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).
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
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Francois, tu n'as pas lu mon dernier message?
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).
Un simple tour dans la page de manuel de fstab:
*Debian 8*:
Instead of giving the device explicitly, one may indicate the filesystem that is to be mounted by its UUID or LABEL (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot' or
`UUID>6be9de-8139-11d1-9106-a43f08d823a6'.
It's also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).
*Debian 7*:
Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by
its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g.,
`LABEL=Boot' or `UUID>6be9de-8139-11d1-9106-a43f08d823a6'. This will make the system more robust: adding or
removing a SCSI disk changes the disk device name but not the filesystem volume label.
Comme je te l'ai déjà signalé, la syntaxe "UUID=<uuid>" fonctionne dans tous les cas et je ne vois pas de rapport avec systemd.
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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.
Maintenant, t'as le choix:
- Par exemple tu peux faire en sorte que toutes les clefs usb que tu branches sur tel port usb soient montées dans /media/MonDossierPortUsb (donc on utilise by-path).
- Ou chaque clef usb doit être montée dans son dossier spécifique quelque soit le port sur lequel tu les branches (là, on est by-id, label ou propriété inhérente à chaque clef).
Bref, en anglais on dirait que c'est une question de "policy" (j'arrive pas à traduire ce mot),
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
Petite info pour faciliter la recherche de propriétés disons de /dev/sda:
~ # udevadm info -a -n sda
[...]
looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda':
[...]
ATTR{size}=="500118192"
[...]
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0':
[...]
ATTRS{model}=="Samsung SSD 840 "
[...]
Ici on voit par exemple que j'ai un disque Samsung de 500118192 blocks et j'ai son chemin. Comme je ne le change jamais de branchement, si je voulais modifier son comportement lorsqu'il est découvert par le kernel -> udev ou exécuter un programme arbitraire, j'utiliserais son chemin d'accès (by-path).
Un exemple utile, j'ai un disque externe 1Go formaté en ntfs, quand je le branche avant de démarrer, aucun problème, sa ligne dans fstab fait son travail mais si je le branche à chaud ntfs-3g se plaint de ne pas avoir été compilé avec telle ou telle option je sais plus, en tout cas je suis obligé de le monter à la main en root. Donc j'ai ajouté une règle udev qui se base sur sa taille (pourquoi pas, j'ai pas d'autre disque de cette taille), la voici:
ACTION=="add", SUBSYSTEM=="block", ATTR{size}=="1367464844", RUN+="/usr/bin/MonMountDisk-Backup.sh"
J'aurais pu rajouter un SYMLINK+="mes_disques/disk1G" pour voir apparaître le disque dans /dev/mes_disques/disk1G.
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).
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
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Francois, tu n'as pas lu mon dernier message?
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).
Un simple tour dans la page de manuel de fstab:
*Debian 8*:
Instead of giving the device explicitly, one may indicate the filesystem that is to be mounted by its UUID or LABEL (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot' or
`UUID>6be9de-8139-11d1-9106-a43f08d823a6'.
It's also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).
*Debian 7*:
Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by
its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g.,
`LABEL=Boot' or `UUID>6be9de-8139-11d1-9106-a43f08d823a6'. This will make the system more robust: adding or
removing a SCSI disk changes the disk device name but not the filesystem volume label.
Comme je te l'ai déjà signalé, la syntaxe "UUID=<uuid>" fonctionne dans tous les cas et je ne vois pas de rapport avec systemd.
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans le 2ème cas (wheezy).
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
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.
Maintenant, t'as le choix:
- Par exemple tu peux faire en sorte que toutes les clefs usb que tu branches sur tel port usb soient montées dans /media/MonDossierPortUsb (donc on utilise by-path).
- Ou chaque clef usb doit être montée dans son dossier spécifique quelque soit le port sur lequel tu les branches (là, on est by-id, label ou propriété inhérente à chaque clef).
Bref, en anglais on dirait que c'est une question de "policy" (j'arrive pas à traduire ce mot),
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
Petite info pour faciliter la recherche de propriétés disons de /dev/sda:
~ # udevadm info -a -n sda
[...]
looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda':
[...]
ATTR{size}=="500118192"
[...]
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0':
[...]
ATTRS{model}=="Samsung SSD 840 "
[...]
Ici on voit par exemple que j'ai un disque Samsung de 500118192 blocks et j'ai son chemin. Comme je ne le change jamais de branchement, si je voulais modifier son comportement lorsqu'il est découvert par le kernel -> udev ou exécuter un programme arbitraire, j'utiliserais son chemin d'accès (by-path).
Un exemple utile, j'ai un disque externe 1Go formaté en ntfs, quand je le branche avant de démarrer, aucun problème, sa ligne dans fstab fait son travail mais si je le branche à chaud ntfs-3g se plaint de ne pas avoir été compilé avec telle ou telle option je sais plus, en tout cas je suis obligé de le monter à la main en root. Donc j'ai ajouté une règle udev qui se base sur sa taille (pourquoi pas, j'ai pas d'autre disque de cette taille), la voici:
ACTION=="add", SUBSYSTEM=="block", ATTR{size}=="1367464844", RUN+="/usr/bin/MonMountDisk-Backup.sh"
J'aurais pu rajouter un SYMLINK+="mes_disques/disk1G" pour voir apparaître le disque dans /dev/mes_disques/disk1G.
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).
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
Et bien sûr 512 au lieu de 446 si tu veux effacer également la table des partitions.
Si tu avais un partitionnement gpt ce serait un peu plus complexe et il vaut mieux laisser faire un outil dédié comme gdisk.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Là, je me place dans une optique de machine serveur avec des tiroirs.
Si, lorsque le disque change d'emplacement, le lien symbolique change
aussi de nom, ça ne peut pas convenir dans mon cas. Il me faut un symlink
qui ne dépende *que* du disque pas de son emplacement.
Au risque de paraître redondant, /dev/disk/by-id est fait pour toi. (Je t'ai donné mon exemple à base de clef USB, bien sûr je ne la branche pas toujours sur le même port, surtout quand ce n'est pas la même machine !)
(by-path, lui, au contraire dépend du port et pas du périphérique particulier qui y est branché)
Au risque de paraître redondant, /dev/disk/by-id est fait pour toi. (Je t'ai donné mon exemple à base de clef USB, bien sûr je ne la branche pas toujours sur le même port, surtout quand ce n'est pas la même machine !)
(by-path, lui, au contraire dépend du port et pas du périphérique particulier qui y est branché)
Au risque de paraître redondant, /dev/disk/by-id est fait pour toi. (Je t'ai donné mon exemple à base de clef USB, bien sûr je ne la branche pas toujours sur le même port, surtout quand ce n'est pas la même machine !)
(by-path, lui, au contraire dépend du port et pas du périphérique particulier qui y est branché)
Pascal Hambourg , dans le message <mett65$1igc$, a
écrit :C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Quand il n'y a pas de moyen fiable de faire les choses, il vaut mieux
prendre le temps d'en inventer un proprement que bricoler un truc crade
comme les UUID dans le contenu.
Pascal Hambourg , dans le message <mett65$1igc$1@saria.nerim.net>, a
écrit :
C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Quand il n'y a pas de moyen fiable de faire les choses, il vaut mieux
prendre le temps d'en inventer un proprement que bricoler un truc crade
comme les UUID dans le contenu.
Pascal Hambourg , dans le message <mett65$1igc$, a
écrit :C'est un peu le but, il me semble. Et puis il n'y a guère de moyen
fiable en l'absence de méta-données extérieures au contenu, ce qui était
le cas quand on a commencé à utiliser les UUID (pas encore de GPT).
Quand il n'y a pas de moyen fiable de faire les choses, il vaut mieux
prendre le temps d'en inventer un proprement que bricoler un truc crade
comme les UUID dans le contenu.
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
Ah peut-être. J'avoue que le coup des partitions primaires/étendues ne
m'a jamais posé de problème personnellement, à part le côté « esthétique ».
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
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 ?
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :
C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
Ah peut-être. J'avoue que le coup des partitions primaires/étendues ne
m'a jamais posé de problème personnellement, à part le côté « esthétique ».
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
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 ?
Bonjour,
Le 24/03/2015 09:53, Pascal Hambourg a écrit :C'est loin d'être le plus gros avantage de GPT. Loin devant je place la
disparition de la distinction entre partitions primaire, étendue et logique.
Ah peut-être. J'avoue que le coup des partitions primaires/étendues ne
m'a jamais posé de problème personnellement, à part le côté « esthétique ».
Quant à un disque brut sans partition ni fs a priori, à part utiliser
une règle udev spécifique sur le S/N où un truc dans le genre, je ne
pense pas qu'il y ait d'autre possibilité.
Si, avec le liens symboliques dans /dev/disk/by-id/ ou
/dev/disk/by-path/ comme déjà signalé.
Ah oui, pardon, j'avais zappé. Mais ces liens symboliques dépendent-ils
du disque en lui-même (par exemple de son S/N) ou de son emplacement ?
Ah, si : certains outils de partitionnement, et notamment ceux inclus
dans l'installateur de distributions comme Debian, considèrent que le
disque est au format GPT s'il comporte une signature GPT, même si le MBR
n'est manifestement pas conforme au format GPT (signe que le disque a
été repartitionné au format MSDOS par un outil non compatible GPT). Par
conséquent ils ne voient pas les partitions existantes. Attention donc à
la réutilisation au format MSDOS d'un disque précédemment au format GPT.
Bien effacer la signature GPT avant.
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 ?