J'utilisais depuis des années une procédure personnelle très simple pour
sauvegarder intégralement mon système linux:
- booter depuis un live-cd
- monter le volume système
- tar du volume vers un serveur (donc sans les données qui sont montées
sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un
nouveau disque, de créer la partition système avec le même nom (par
exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver
exactement le même système. Puis démarrage et restauration du home si
nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette
procédure échoue, puisqu'un nouveau formatage en recréé un
aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour
revenir à un système opérationnel, incluant une réinstallation de base
puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de
grub (sur une partition séparée) qui continuait à vouloir booter avec
l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé /
réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en
imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir
toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce
problème? Par exemple en revenant à l'ancienne dénomination y-compris
dans le grub?
Edit: 12.04 (je suis conservateur mais quand même !)
denis.paris
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de grub (sur une partition séparée) qui continuait à vouloir booter avec l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé / réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce problème? Par exemple en revenant à l'ancienne dénomination y-compris dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Les suggestions restent les bienvenues.
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour
sauvegarder intégralement mon système linux:
- booter depuis un live-cd
- monter le volume système
- tar du volume vers un serveur (donc sans les données qui sont montées
sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un
nouveau disque, de créer la partition système avec le même nom (par
exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver
exactement le même système. Puis démarrage et restauration du home si
nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette
procédure échoue, puisqu'un nouveau formatage en recréé un
aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour
revenir à un système opérationnel, incluant une réinstallation de base
puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de
grub (sur une partition séparée) qui continuait à vouloir booter avec
l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé /
réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en
imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir
toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce
problème? Par exemple en revenant à l'ancienne dénomination y-compris
dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes
amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de grub (sur une partition séparée) qui continuait à vouloir booter avec l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé / réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce problème? Par exemple en revenant à l'ancienne dénomination y-compris dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Les suggestions restent les bienvenues.
Sergio
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Un petit : sudo tune2fs -U <l'UUID desirée> /dev/<votre partition> après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd
- monter le volume système
- tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom
(par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et
restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un
aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation
de base puis la modification de fstab puis une restauration, etc...
Un petit :
sudo tune2fs -U <l'UUID desirée> /dev/<votre partition>
après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Un petit : sudo tune2fs -U <l'UUID desirée> /dev/<votre partition> après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
denis.paris
Le 23/01/2014 13:10, Sergio a écrit :
Un petit : sudo tune2fs -U <l'UUID desirée> /dev/<votre partition> après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
En effet, merci, je venais juste de m'en rendre compte.
Le 23/01/2014 13:10, Sergio a écrit :
Un petit :
sudo tune2fs -U <l'UUID desirée> /dev/<votre partition>
après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
En effet, merci, je venais juste de m'en rendre compte.
Un petit : sudo tune2fs -U <l'UUID desirée> /dev/<votre partition> après formatage ?
Tiré de la doc : http://doc.ubuntu-fr.org/uuid_et_label
En effet, merci, je venais juste de m'en rendre compte.
denis.paris
Le 23/01/2014 13:08, denis.paris a écrit :
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de grub (sur une partition séparée) qui continuait à vouloir booter avec l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé / réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce problème? Par exemple en revenant à l'ancienne dénomination y-compris dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Les suggestions restent les bienvenues.
Testé à l'arrache, vite-fait sur une machine virtuelle de test: ça fonctionne parfaitement. Il suffit donc de garder trace des anciens UUID pour pouvoir les remettre à l'identique:
blkid > UUID.lst (en root)
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Le 23/01/2014 13:08, denis.paris a écrit :
Le 23/01/2014 12:59, denis.paris a écrit :
J'utilisais depuis des années une procédure personnelle très simple pour
sauvegarder intégralement mon système linux:
- booter depuis un live-cd
- monter le volume système
- tar du volume vers un serveur (donc sans les données qui sont montées
sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un
nouveau disque, de créer la partition système avec le même nom (par
exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver
exactement le même système. Puis démarrage et restauration du home si
nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette
procédure échoue, puisqu'un nouveau formatage en recréé un
aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour
revenir à un système opérationnel, incluant une réinstallation de base
puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de
grub (sur une partition séparée) qui continuait à vouloir booter avec
l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé /
réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en
imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir
toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce
problème? Par exemple en revenant à l'ancienne dénomination y-compris
dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes
amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Les suggestions restent les bienvenues.
Testé à l'arrache, vite-fait sur une machine virtuelle de test: ça
fonctionne parfaitement. Il suffit donc de garder trace des anciens UUID
pour pouvoir les remettre à l'identique:
blkid > UUID.lst (en root)
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part
compliquer la vie des utilisateurs, l'ancienne notation était très
simple à mémoriser.
J'utilisais depuis des années une procédure personnelle très simple pour sauvegarder intégralement mon système linux:
- booter depuis un live-cd - monter le volume système - tar du volume vers un serveur (donc sans les données qui sont montées sur home)
Ainsi en cas de crash d'un disque il suffit normalement de mettre un nouveau disque, de créer la partition système avec le même nom (par exemple "/dev/sda6") et de restaurer tous les fichiers pour retrouver exactement le même système. Puis démarrage et restauration du home si nécessaire.
Malheureusement depuis la mise en oeuvre de ces satanés "UUID" cette procédure échoue, puisqu'un nouveau formatage en recréé un aléatoirement. Récemment j'ai eu un crash et j'ai beaucoup ramé pour revenir à un système opérationnel, incluant une réinstallation de base puis la modification de fstab puis une restauration, etc...
Le problème que j'ai eu n'était pas seulement au niveau du fstab mais de grub (sur une partition séparée) qui continuait à vouloir booter avec l'ancien UUID. J'ai donc restauré tout sauf /boot, puis désinstallé / réinstallé le noyau pour resynchroniser le tout... Bref, pas très propre.
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Si ce n'est pas possible, auriez-vous une suggestion pour contourner ce problème? Par exemple en revenant à l'ancienne dénomination y-compris dans le grub?
Ma version linux est xubuntu 10.04
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Les suggestions restent les bienvenues.
Testé à l'arrache, vite-fait sur une machine virtuelle de test: ça fonctionne parfaitement. Il suffit donc de garder trace des anciens UUID pour pouvoir les remettre à l'identique:
blkid > UUID.lst (en root)
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Francois Lafont
Bonjour,
Le 23/01/2014 14:31, denis.paris a écrit :
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Imagine que tu as une machine avec 2 disques /dev/sda et /dev/sdb et un fstab qui utilise ce type de nom pour faire les montages.
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque physique, alors lors du prochain reboot tu n'as pas la garantie absolue que le disque qui s'appelait sda avant le reboot s'appelle toujours sda après, et que celui qui s'appelait sdb avant le reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer des permutations de noms). Et donc, lors du démarrage, tu peux avoir quelques surprises quand le système voudra monter sda1 sur / alors que sda1 n'est plus ta partition système.
Avec les UUID dans le fstab, tu peux être sûr que les UUID n'auront pas changé et ton reboot, dans ce cas, se passera comme d'habitude.
-- François Lafont
Bonjour,
Le 23/01/2014 14:31, denis.paris a écrit :
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part
compliquer la vie des utilisateurs, l'ancienne notation était très
simple à mémoriser.
Imagine que tu as une machine avec 2 disques /dev/sda et
/dev/sdb et un fstab qui utilise ce type de nom pour faire
les montages.
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque
physique, alors lors du prochain reboot tu n'as pas la garantie
absolue que le disque qui s'appelait sda avant le reboot s'appelle
toujours sda après, et que celui qui s'appelait sdb avant le
reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer
des permutations de noms). Et donc, lors du démarrage, tu
peux avoir quelques surprises quand le système voudra monter
sda1 sur / alors que sda1 n'est plus ta partition système.
Avec les UUID dans le fstab, tu peux être sûr que les UUID
n'auront pas changé et ton reboot, dans ce cas, se passera
comme d'habitude.
Cela-dit, je n'ai jamais vraiment compris l’intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Imagine que tu as une machine avec 2 disques /dev/sda et /dev/sdb et un fstab qui utilise ce type de nom pour faire les montages.
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque physique, alors lors du prochain reboot tu n'as pas la garantie absolue que le disque qui s'appelait sda avant le reboot s'appelle toujours sda après, et que celui qui s'appelait sdb avant le reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer des permutations de noms). Et donc, lors du démarrage, tu peux avoir quelques surprises quand le système voudra monter sda1 sur / alors que sda1 n'est plus ta partition système.
Avec les UUID dans le fstab, tu peux être sûr que les UUID n'auront pas changé et ton reboot, dans ce cas, se passera comme d'habitude.
-- François Lafont
Sergio
Le 23/01/2014 18:27, Francois Lafont a écrit :
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque physique, alors lors du prochain reboot tu n'as pas la garantie absolue que le disque qui s'appelait sda avant le reboot s'appelle toujours sda après, et que celui qui s'appelait sdb avant le reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer des permutations de noms). Et donc, lors du démarrage, tu peux avoir quelques surprises quand le système voudra monter sda1 sur / alors que sda1 n'est plus ta partition système.
J'ai eu un cas où aléatoirement, le disque dur (unique...) se retrouvait en sde, les sda/sdb/sdc/sdd (lecteur de cartes mémoires) étant "peuplés" avant le disque dur.
Ça ne perturbait rien, mais ça faisait bizarre...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 23/01/2014 18:27, Francois Lafont a écrit :
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque
physique, alors lors du prochain reboot tu n'as pas la garantie
absolue que le disque qui s'appelait sda avant le reboot s'appelle
toujours sda après, et que celui qui s'appelait sdb avant le
reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer
des permutations de noms). Et donc, lors du démarrage, tu
peux avoir quelques surprises quand le système voudra monter
sda1 sur / alors que sda1 n'est plus ta partition système.
J'ai eu un cas où aléatoirement, le disque dur (unique...) se retrouvait en sde, les sda/sdb/sdc/sdd (lecteur de cartes mémoires)
étant "peuplés" avant le disque dur.
Ça ne perturbait rien, mais ça faisait bizarre...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Si jamais tu éteins ta machine et que tu ajoutes un 3e disque physique, alors lors du prochain reboot tu n'as pas la garantie absolue que le disque qui s'appelait sda avant le reboot s'appelle toujours sda après, et que celui qui s'appelait sdb avant le reboot s'appelle toujours sdb (l'ajout de 3e disque peut provoquer des permutations de noms). Et donc, lors du démarrage, tu peux avoir quelques surprises quand le système voudra monter sda1 sur / alors que sda1 n'est plus ta partition système.
J'ai eu un cas où aléatoirement, le disque dur (unique...) se retrouvait en sde, les sda/sdb/sdc/sdd (lecteur de cartes mémoires) étant "peuplés" avant le disque dur.
Ça ne perturbait rien, mais ça faisait bizarre...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
yamo'
Salut,
denis.paris a tapoté, le 23/01/2014 14:31:
blkid > UUID.lst (en root)
Sur debian 7, pas besoin d'être root, il faut taper le chemin entier : /sbin/blkid
-- Stéphane
Salut,
denis.paris a tapoté, le 23/01/2014 14:31:
blkid > UUID.lst (en root)
Sur debian 7, pas besoin d'être root, il faut taper le chemin entier :
/sbin/blkid
Sur debian 7, pas besoin d'être root, il faut taper le chemin entier : /sbin/blkid
-- Stéphane
Pascal Hambourg
denis.paris a écrit :
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Pas besoin de tune2fs. e2mkfs (ou mkfs.ext[234]) a aussi une option -U permettant de spécifier l'UUID dès la création du système de fichiers.
denis.paris a écrit :
Le plus simple pour moi serait de pouvoir formater une partition en
imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir
toujours le même. D'où le titre du post.
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes
amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Pas besoin de tune2fs. e2mkfs (ou mkfs.ext[234]) a aussi une option -U
permettant de spécifier l'UUID dès la création du système de fichiers.
Le plus simple pour moi serait de pouvoir formater une partition en imposant l'UUID, voire de pouvoir modifier cet UUID afin d'avoir toujours le même. D'où le titre du post.
Oups, je me réponds à moi-même, j'aurais dû mieux faire confiance à mes amis: j'ai trouvé avec "tune2fs -U", mais il me reste à faire des tests.
Pas besoin de tune2fs. e2mkfs (ou mkfs.ext[234]) a aussi une option -U permettant de spécifier l'UUID dès la création du système de fichiers.
Pascal Hambourg
denis.paris a écrit :
Cela-dit, je n'ai jamais vraiment compris l'intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Les UUID assurent la persistance de la désignation des volumes (systèmes de fichiers, swap...) indépendamment du nommage des périphériques sous-jacents qui n'est pas persistant.
Comme déjà dit, l'ajout ou la suppression d'un "disque" est susceptible de modifier le nommage des autres disques. Le "disque" peut être aussi la bête clé USB qu'on a laissé branchée. De même, on y pense moins, l'ajout ou la suppression d'une partition peut modifier le nommage des autres partitions du disque. Enfin, le passage des anciens pilotes IDE du noyau (qui nommaient les disques en fonction de leur position physique) aux pilotes PATA/SATA basés sur libata (qui nomment les disques en fonction de leur ordre d'énumération) combiné à la méthode actuelle de gestion des périphériques "hotplug" (plus aucun pilote en dur dans le noyau, identification asynchrone par udev qui charge les modules correspondants) peuvent faire varier l'ordre de nommage des périphériques d'un démarrage à l'autre même sans changement du matériel.
D'ailleurs, md (RAID logiciel) et LVM utilisent en interne des UUID pour retrouver leurs petits.
Si tu trouves les UUID trop difficiles à mémoriser, tu peux les remplacer par des LABELs.
denis.paris a écrit :
Cela-dit, je n'ai jamais vraiment compris l'intérêt des UUID, à part
compliquer la vie des utilisateurs, l'ancienne notation était très
simple à mémoriser.
Les UUID assurent la persistance de la désignation des volumes (systèmes
de fichiers, swap...) indépendamment du nommage des périphériques
sous-jacents qui n'est pas persistant.
Comme déjà dit, l'ajout ou la suppression d'un "disque" est susceptible
de modifier le nommage des autres disques. Le "disque" peut être aussi
la bête clé USB qu'on a laissé branchée. De même, on y pense moins,
l'ajout ou la suppression d'une partition peut modifier le nommage des
autres partitions du disque. Enfin, le passage des anciens pilotes IDE
du noyau (qui nommaient les disques en fonction de leur position
physique) aux pilotes PATA/SATA basés sur libata (qui nomment les
disques en fonction de leur ordre d'énumération) combiné à la méthode
actuelle de gestion des périphériques "hotplug" (plus aucun pilote en
dur dans le noyau, identification asynchrone par udev qui charge les
modules correspondants) peuvent faire varier l'ordre de nommage des
périphériques d'un démarrage à l'autre même sans changement du matériel.
D'ailleurs, md (RAID logiciel) et LVM utilisent en interne des UUID pour
retrouver leurs petits.
Si tu trouves les UUID trop difficiles à mémoriser, tu peux les
remplacer par des LABELs.
Cela-dit, je n'ai jamais vraiment compris l'intérêt des UUID, à part compliquer la vie des utilisateurs, l'ancienne notation était très simple à mémoriser.
Les UUID assurent la persistance de la désignation des volumes (systèmes de fichiers, swap...) indépendamment du nommage des périphériques sous-jacents qui n'est pas persistant.
Comme déjà dit, l'ajout ou la suppression d'un "disque" est susceptible de modifier le nommage des autres disques. Le "disque" peut être aussi la bête clé USB qu'on a laissé branchée. De même, on y pense moins, l'ajout ou la suppression d'une partition peut modifier le nommage des autres partitions du disque. Enfin, le passage des anciens pilotes IDE du noyau (qui nommaient les disques en fonction de leur position physique) aux pilotes PATA/SATA basés sur libata (qui nomment les disques en fonction de leur ordre d'énumération) combiné à la méthode actuelle de gestion des périphériques "hotplug" (plus aucun pilote en dur dans le noyau, identification asynchrone par udev qui charge les modules correspondants) peuvent faire varier l'ordre de nommage des périphériques d'un démarrage à l'autre même sans changement du matériel.
D'ailleurs, md (RAID logiciel) et LVM utilisent en interne des UUID pour retrouver leurs petits.
Si tu trouves les UUID trop difficiles à mémoriser, tu peux les remplacer par des LABELs.
