Sur un portable sous xubuntu, j'ai voulu remplacer le disque système
(pour mettre un SSD), en recopiant la partition du système pour ne pas à
avoir à réinstaller. J'ai donc
- mis le nouveau disque à la place de l'ancien, et connecté l'ancien en USB
- booté sur une clé USB
- avec gparted, créé une partition de même taille que la partition
système de l'ancien disque,
- recopié la partition sur le nouveau disque par
dd if=/dev/sdb1 of=/dev/sda1 bs=4096 conv=notrunc,noerror
- flagué la nouvelle partition comme "boot"
- monté la partition et édité /etc/fstab pour désactiver le montage du swap
- rebooté
...et là ça ne marche pas. Passé l'étape du BIOS j'ai un écran noir
Le Sat, 31 Mar 2012 15:01:27 +0200, pehache a écrit:
Tu peux développer ?
Par exemple les blocs ne sont pas nécessairement alignés sur les mêmes valeurs, ce qui fait qu'une lecture d'un bloc peut en accéder deux, ou une écriture d'un bloc forcer une lecture et deux ecritures (lecture- modification-écriture). Performance divisée par 4 garantie.
-- Software is like sex: It's better when it's free. Linus Torvalds
Le Sat, 31 Mar 2012 15:01:27 +0200, pehache a écrit:
Tu peux développer ?
Par exemple les blocs ne sont pas nécessairement alignés sur les mêmes
valeurs, ce qui fait qu'une lecture d'un bloc peut en accéder deux, ou
une écriture d'un bloc forcer une lecture et deux ecritures (lecture-
modification-écriture). Performance divisée par 4 garantie.
--
Software is like sex: It's better when it's free.
Linus Torvalds
Le Sat, 31 Mar 2012 15:01:27 +0200, pehache a écrit:
Tu peux développer ?
Par exemple les blocs ne sont pas nécessairement alignés sur les mêmes valeurs, ce qui fait qu'une lecture d'un bloc peut en accéder deux, ou une écriture d'un bloc forcer une lecture et deux ecritures (lecture- modification-écriture). Performance divisée par 4 garantie.
-- Software is like sex: It's better when it's free. Linus Torvalds
Pascal Hambourg
pehache a écrit :
En fait j'ai installé un xubuntu from scratch sur le nouveau disque, donc avec tout ce qu'il faut pour booter sur la partition montée en /, et ensuite j'ai remplacé le contenu de cette partition par le contenu de la partition système de l'ancien disque (plus la "bidouille" dans le fstab).
Ca me parait normal que ça marche, non ?
Non, pas forcément. Cela dépend notamment du type du chargeur d'amorçage (grub, lilo) et de la façon dont il a été installé. En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
pehache a écrit :
En fait j'ai installé un xubuntu from scratch sur le nouveau disque,
donc avec tout ce qu'il faut pour booter sur la partition montée en /,
et ensuite j'ai remplacé le contenu de cette partition par le contenu de
la partition système de l'ancien disque (plus la "bidouille" dans le fstab).
Ca me parait normal que ça marche, non ?
Non, pas forcément. Cela dépend notamment du type du chargeur d'amorçage
(grub, lilo) et de la façon dont il a été installé.
En tout cas la suppression de l'UUID de la racine dans le fstab me
paraît totalement superflue.
En fait j'ai installé un xubuntu from scratch sur le nouveau disque, donc avec tout ce qu'il faut pour booter sur la partition montée en /, et ensuite j'ai remplacé le contenu de cette partition par le contenu de la partition système de l'ancien disque (plus la "bidouille" dans le fstab).
Ca me parait normal que ça marche, non ?
Non, pas forcément. Cela dépend notamment du type du chargeur d'amorçage (grub, lilo) et de la façon dont il a été installé. En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
Francois Lafont
Bonjour,
Le 31/03/2012 15:51, Pascal Hambourg a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque /dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb, je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le « nouveau » /dev/sdc). Si j'éteins mon système et que je débranche physiquement le « vieux » disque (/dev/sdb) puis que je redémarre, est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien prendra-t-il le non de l'ancien (/dev/sdb) ?
-- François Lafont
Bonjour,
Le 31/03/2012 15:51, Pascal Hambourg a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me
paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans
/etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom
pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque
/dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de
brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une
seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb,
je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le
« nouveau » /dev/sdc). Si j'éteins mon système et que je débranche
physiquement le « vieux » disque (/dev/sdb) puis que je redémarre,
est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien
prendra-t-il le non de l'ancien (/dev/sdb) ?
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque /dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb, je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le « nouveau » /dev/sdc). Si j'éteins mon système et que je débranche physiquement le « vieux » disque (/dev/sdb) puis que je redémarre, est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien prendra-t-il le non de l'ancien (/dev/sdb) ?
-- François Lafont
YBM
Francois Lafont a écrit :
Bonjour,
Le 31/03/2012 15:51, Pascal Hambourg a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque /dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb, je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le « nouveau » /dev/sdc). Si j'éteins mon système et que je débranche physiquement le « vieux » disque (/dev/sdb) puis que je redémarre, est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien prendra-t-il le non de l'ancien (/dev/sdb) ?
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Attention, cependant, aux systèmes de duplication genre ghost qui sont bien fichus de reconstruire les systèmes de fichiers, et donc les UUID sans mettre à jour la configuration de GRUB et fstab...
Francois Lafont a écrit :
Bonjour,
Le 31/03/2012 15:51, Pascal Hambourg a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me
paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans
/etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom
pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque
/dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de
brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une
seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb,
je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le
« nouveau » /dev/sdc). Si j'éteins mon système et que je débranche
physiquement le « vieux » disque (/dev/sdb) puis que je redémarre,
est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien
prendra-t-il le non de l'ancien (/dev/sdb) ?
Dans ton scénario il est probable que oui, mais seulement probable, il
n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour
nommer les périphériques. On peut avoir des surprises. RHEL 6 est
particulièrement tordue à ce niveau : une disque peut même changer de
nom dans /dev après avoir été partitionné si l'on reboot. Conclusion :
en dehors des volumes logiques dont le nom est décidé à leur création,
il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les
labels ne sont pas une solution tenable).
Attention, cependant, aux systèmes de duplication genre ghost qui sont
bien fichus de reconstruire les systèmes de fichiers, et donc les UUID
sans mettre à jour la configuration de GRUB et fstab...
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
Je m'explique. Imaginons que j'ai sur mon système un « vieux » disque /dev/sdb avec une seule partition /dev/sdb1. Un beau jour, je décide de brancher un « nouveau » disque qui s'appellera /dev/sdc avec aussi une seule partition /dev/sdc1. Imaginons que le « vieux » disque /dev/sdb, je souhaite m'en débarrasser (parce que j'y ai copié son contenu dans le « nouveau » /dev/sdc). Si j'éteins mon système et que je débranche physiquement le « vieux » disque (/dev/sdb) puis que je redémarre, est-ce que mon « nouveau » disque s'appellera toujours /dev/sdc ou bien prendra-t-il le non de l'ancien (/dev/sdb) ?
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Attention, cependant, aux systèmes de duplication genre ghost qui sont bien fichus de reconstruire les systèmes de fichiers, et donc les UUID sans mettre à jour la configuration de GRUB et fstab...
Sergio
Le Sun, 01 Apr 2012 17:24:33 +0200, Francois Lafont a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
"Vaut mieux utiliser les UUID" du moins pour un système stable. Pour dépanner on peut...
Exemple (mon cas) : Un disque IDE (avec Windows) et un disque SATA (avec Linux), et en prime un lecteur ZIP en IDE. Je peux désactiver chacun de ces bestiaux via le BIOS.
Cas normal (tous les disques sont activés) : disque IDE : sda Lecteur ZIP : sdb Disque SATA : sdc ... Et ça boote sur le SATA.
Par contre, si je désactive l'IDE ou/et le ZIP : Le disque SATA se retrouve en sdb ou sda... Donc il vaut mieux utiliser l'identification par UUID...
Et mieux : depuis, j'ai migré le SATA dans une autre bécane : Ben ça marchait tout seul. J'ai néanmoins réinstaller, pour avoir un système 64 bits (la précédente ne le connaissait pas).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le Sun, 01 Apr 2012 17:24:33 +0200, Francois Lafont a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me
paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans
/etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom
pour une partition comme /dev/sdc1 était quelque chose de persistant.
"Vaut mieux utiliser les UUID" du moins pour un système stable. Pour
dépanner on peut...
Exemple (mon cas) :
Un disque IDE (avec Windows) et un disque SATA (avec Linux), et en prime
un lecteur ZIP en IDE. Je peux désactiver chacun de ces bestiaux via le
BIOS.
Cas normal (tous les disques sont activés) :
disque IDE : sda
Lecteur ZIP : sdb
Disque SATA : sdc
... Et ça boote sur le SATA.
Par contre, si je désactive l'IDE ou/et le ZIP : Le disque SATA se
retrouve en sdb ou sda...
Donc il vaut mieux utiliser l'identification par UUID...
Et mieux : depuis, j'ai migré le SATA dans une autre bécane : Ben ça
marchait tout seul. J'ai néanmoins réinstaller, pour avoir un système 64
bits (la précédente ne le connaissait pas).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Le Sun, 01 Apr 2012 17:24:33 +0200, Francois Lafont a écrit :
En tout cas la suppression de l'UUID de la racine dans le fstab me paraît totalement superflue.
À propos de cette histoire de "UUID=xxxxxx" qu'on retrouve dans /etc/fstab à la place des /dev/sdxx, j'aurais voulu savoir si un nom pour une partition comme /dev/sdc1 était quelque chose de persistant.
"Vaut mieux utiliser les UUID" du moins pour un système stable. Pour dépanner on peut...
Exemple (mon cas) : Un disque IDE (avec Windows) et un disque SATA (avec Linux), et en prime un lecteur ZIP en IDE. Je peux désactiver chacun de ces bestiaux via le BIOS.
Cas normal (tous les disques sont activés) : disque IDE : sda Lecteur ZIP : sdb Disque SATA : sdc ... Et ça boote sur le SATA.
Par contre, si je désactive l'IDE ou/et le ZIP : Le disque SATA se retrouve en sdb ou sda... Donc il vaut mieux utiliser l'identification par UUID...
Et mieux : depuis, j'ai migré le SATA dans une autre bécane : Ben ça marchait tout seul. J'ai néanmoins réinstaller, pour avoir un système 64 bits (la précédente ne le connaissait pas).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Francois Lafont
Le 01/04/2012 17:37, YBM a écrit :
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
-- François Lafont
Le 01/04/2012 17:37, YBM a écrit :
Dans ton scénario il est probable que oui, mais seulement probable, il
n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour
nommer les périphériques. On peut avoir des surprises. RHEL 6 est
particulièrement tordue à ce niveau : une disque peut même changer de
nom dans /dev après avoir été partitionné si l'on reboot. Conclusion :
en dehors des volumes logiques dont le nom est décidé à leur création,
il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les
labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
-- François Lafont
Erwan David
Francois Lafont écrivait :
Le 01/04/2012 17:37, YBM a écrit :
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Dans ton scénario il est probable que oui, mais seulement probable, il
n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour
nommer les périphériques. On peut avoir des surprises. RHEL 6 est
particulièrement tordue à ce niveau : une disque peut même changer de
nom dans /dev après avoir été partitionné si l'on reboot. Conclusion :
en dehors des volumes logiques dont le nom est décidé à leur création,
il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les
labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Nicolas George
Erwan David , dans le message , a écrit :
Ou des LABEL, ce qui est quand même nettement plud lisible.
Ou utiliser LVM.
Erwan David , dans le message <m2ty13nrc5.fsf@rail.eu.org>, a écrit :
Ou des LABEL, ce qui est quand même nettement plud lisible.
Ou des LABEL, ce qui est quand même nettement plud lisible.
Ou utiliser LVM.
Emmanuel Florac
Le Sun, 01 Apr 2012 17:37:04 +0200, YBM a écrit:
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques.
Depuis toujours je continue à utiliser /dev/sdxx et je n'ai jamais eu de problème. Sous Debian comme slackware, en tout cas, un disque garde son identifiant.
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
Le Sun, 01 Apr 2012 17:37:04 +0200, YBM a écrit:
Celà dépend de la façon dont udev est configuré par la distribution pour
nommer les périphériques.
Depuis toujours je continue à utiliser /dev/sdxx et je n'ai jamais eu de
problème. Sous Debian comme slackware, en tout cas, un disque garde son
identifiant.
--
The bearing of a child takes 9 months, no matter how many women are
assigned.
Fred Brooks
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques.
Depuis toujours je continue à utiliser /dev/sdxx et je n'ai jamais eu de problème. Sous Debian comme slackware, en tout cas, un disque garde son identifiant.
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
YBM
Le 01.04.2012 22:13, Erwan David a écrit :
Francois Lafont écrivait :
Le 01/04/2012 17:37, YBM a écrit :
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
Et un jour futur tu branches un second disque qui ne servait plus, qui se trouve avoir contenu une installation d'une distribution, et tu te retrouves avec les labels en double, le mauvais /usr (ou /var, peu importe) monté au démarrage...
Dans ton scénario il est probable que oui, mais seulement probable, il
n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour
nommer les périphériques. On peut avoir des surprises. RHEL 6 est
particulièrement tordue à ce niveau : une disque peut même changer de
nom dans /dev après avoir été partitionné si l'on reboot. Conclusion :
en dehors des volumes logiques dont le nom est décidé à leur création,
il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les
labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
Et un jour futur tu branches un second disque qui ne servait plus, qui
se trouve avoir contenu une installation d'une distribution, et tu te
retrouves avec les labels en double, le mauvais /usr (ou /var, peu
importe) monté au démarrage...
Dans ton scénario il est probable que oui, mais seulement probable, il n'y a aucune garantie.
Celà dépend de la façon dont udev est configuré par la distribution pour nommer les périphériques. On peut avoir des surprises. RHEL 6 est particulièrement tordue à ce niveau : une disque peut même changer de nom dans /dev après avoir été partitionné si l'on reboot. Conclusion : en dehors des volumes logiques dont le nom est décidé à leur création, il n'y a aucune garantie de rien, donc il faut utiliser les UUID. (les labels ne sont pas une solution tenable).
Ok. Merci YBM pour ces précisions. Donc, il faut des UUID dans /etc/fstab.
Ou des LABEL, ce qui est quand même nettement plud lisible.
Et un jour futur tu branches un second disque qui ne servait plus, qui se trouve avoir contenu une installation d'une distribution, et tu te retrouves avec les labels en double, le mauvais /usr (ou /var, peu importe) monté au démarrage...
