Avoir un UUID avec une partition sans filesystem

Le
Francois Lafont
Bonsoir à tous,

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 :

/dev/disk/by-uuid/07962804-17c6-456a-ac60-28ac5b0db5cc

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 ?

Merci d'avance.

--
François Lafont
Vos réponses Page 2 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26345868
Nicolas George a écrit :
Pascal Hambourg , dans le message é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.



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). Même
les liens dans /dev/disk/by-id dépendent du disque physique, donc
changent si on clone le disque. Pas les UUID, qu'ils soient de partition
ou de système de fichiers.

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.



Je vois ce que tu veux dire.

Dit autrement : tu ne peux pas connaître l'UUID ou le label d'un volume à
moins de déjà savoir lire ce volume.



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.

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.



Justement je viens d'avoir le cas d'un DVD ayant un double format UDF et
ISO9660. Les deux systèmes de fichiers ont le même label. Le montage
automatique est en UDF, peut-être parce que udf est listé en premier
dans fstab. Le shell de GRUB m'a fait un drôle de coup : il a commencé
par lire le DVD en UDF, puis a basculé en ISO sans crier gare, jusqu'à
ce que je décharge le module iso9660.

Il y a aussi le cas des images ISO hybrides qui contiennent un MBR et
une table de partition.

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.



Dans le cas du DVD précité, file l'identifie comme ISO9660.
Nicolas George
Le #26345870
Pascal Hambourg , dans le message é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.

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.



Oui, mais ça reste trop, justement parce qu'il faut implémenter du nouveau
code dans tous ces outils pour chaque nouveau type de filesystem.
Francois Lafont
Le #26345938
Bonjour,

Le 24/03/2015 09:53, Pascal Hambourg a écrit :

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.



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 ».

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,



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.

J'aurais une dernière question : perso, je partitionne avec fdisk depuis
« toujours ». Est-ce que Linux gère bien les partitions GPT ?



Oui.



Ah, parfait.

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.



Ok, merci de pour ce retour d'expérience.

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 ?

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.



Ok, merci beaucoup Pascal pour tous ces conseils.

--
François Lafont
Nicolas George
Le #26345983
mireero , dans le message écrit :
Cependant, on voit que la syntaxe "PARTUUID= " n'est pas mentionnée dans
le 2ème cas (wheezy).



http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?idë0eb262cb4d757983c83241c5fd93ec5ba6b374

Il suffit de regarder quelle version de mount est dans quelle version de
Debian.
mireero
Le #26345982
On 03/25/2015 03:43 PM, Francois Lafont wrote:
Bonjour,



Salut tout le monde,
Francois, tu n'as pas lu mon dernier message?

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.



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).

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.



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), c'est un choix, reconnaissance par chemin ou par
caractéristique. C'est en grande partie grâce à udev (et bien sûr sysfs
qui exporte en "userspace" les événements matériels), que le choix de
nommage et la gestion en général des périphériques a été transférée à
l'administrateur du système (ce qui est une bonne chose).

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.

A plus

--
mireero
Francois Lafont
Le #26345994
Bonjour,

Le 25/03/2015 20:08, mireero a écrit :

Francois, tu n'as pas lu mon dernier message?



Pas au moment où j'ai répondu à Pascal, ce qui n'est pas bien.
Désolé, j'suis un peu à la bourre. ;)

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.

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.



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

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.



Comme j'ai indiqué, je souhaite que le lien symbolique soit constant même
si le disque change d'emplacement.

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),



Ben, je trouve que « politique » est pas si mal comme traduction
mais moi et l'anglais... ;)

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 ?

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.



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.

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.

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 ?

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 ?

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.

Merci de ton aide.

--
François Lafont
Lucas Levrel
Le #26346010
Le 25 mars 2015, Francois Lafont a écrit :

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é)

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
Francois Lafont
Le #26346014
Le 25/03/2015 21:42, Lucas Levrel a écrit :

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 !)



Ah ok, désolé, je n'avais pas compris que « by-id » était
bien constant en fonction du port. Du coup, c'est parfait.

(by-path, lui, au contraire dépend du port et pas du périphérique particulier qui y est branché)



Ok. C'est très clair. Merci pour la réponse.

--
François Lafont
Pascal Hambourg
Le #26346026
Nicolas George a écrit :
Pascal Hambourg , dans le message é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.



Concrètement, tu aurais proposé quoi en restant compatible avec l'existant ?
Pascal Hambourg
Le #26346033
Francois Lafont a écrit :
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 ».



Les partitions logiques sont beaucoup plus pénibles à manipuler et la
structure en liste chaînée est plus fragile qu'une table. Il peut être
impossible de modifier le contenu de la partition étendue si au moins
une de ses partitions logiques est en cours d'utilisation. Le numéro
d'une partitition logique peut changer au gré de la création ou
suppression d'une autre partition logique.

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 ?



by-id dépend du S/N, by-path de l'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 ?



En pratique, ça devrait suffire à éviter le problème évoqué ci-dessus.
En fait effacer les deux premiers secteurs suffirait. En toute rigueur
il faudrait aussi effacer le dernier secteur du disque. Le second et le
dernier secteurs contiennent les en-têtes GPT primaire et secondaire
avec la signature caractéristique qui permet d'identifier un disque en
GPT. Comme dit par mireero, on peut aussi recréer une table de partition
MSDOS avec un outil compatible GPT qui effacera les traces de l'ancien
format GPT.
Publicité
Poster une réponse
Anonyme