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
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.
Changement de noyau, mise à jour de udev, tu peux t'attendre à tout.
Testé sur une RHEL 6.0, installée sur deux disques IDE, ajoute des disques SCSI et les sda/sdb du début deviennent sde/sdf.
Le 01.04.2012 23:17, Emmanuel Florac a écrit :
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.
Changement de noyau, mise à jour de udev, tu peux t'attendre à tout.
Testé sur une RHEL 6.0, installée sur deux disques IDE, ajoute des
disques SCSI et les sda/sdb du début deviennent sde/sdf.
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.
Changement de noyau, mise à jour de udev, tu peux t'attendre à tout.
Testé sur une RHEL 6.0, installée sur deux disques IDE, ajoute des disques SCSI et les sda/sdb du début deviennent sde/sdf.
Nicolas George
Francois Lafont , dans le message <4f78c6af$0$712$, a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Francois Lafont , dans le message
<4f78c6af$0$712$426a34cc@news.free.fr>, a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis
débranchement d'un ancien ?
Francois Lafont , dans le message <4f78c6af$0$712$, a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Francois Lafont
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
-- François Lafont
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis
débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les
noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait
inscrire dans le fichier /etc/fstab étaient stables face à des
modifications du système tels qu'un changement ou une suppression de
disque. C'est tout.
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
-- François Lafont
Francois Lafont
Le 02/04/2012 00:32, Francois Lafont a écrit :
tels qu'un changement ou une suppression de disque. C'est tout.
Je voulais dire « ajout puis suppression de disque ».
-- François Lafont
Le 02/04/2012 00:32, Francois Lafont a écrit :
tels qu'un changement ou une suppression de disque. C'est tout.
Je voulais dire « ajout puis suppression de disque ».
tels qu'un changement ou une suppression de disque. C'est tout.
Je voulais dire « ajout puis suppression de disque ».
-- François Lafont
Doug713705
Le 01-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance de quelle maière les disques vont être 'décalés', on n'à que les étapes 4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui doivent probablement ajouter une couche de problèmes.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Le 01-04-2012, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis
débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les
noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait
inscrire dans le fichier /etc/fstab étaient stables face à des
modifications du système tels qu'un changement ou une suppression de
disque. C'est tout.
Qu'est ce qu'il y a de génant à :
1 - Ajouter/supprimer un disque
2 - Comprendre l'origine du problème si problème il y a (dans
l'hypothèse d'un comportement non prédictibe)
3 - Remettre la configuration dans son état initial
4 - Modifier fstab en fonction des informations qu'on a récupéré à
l'étape 2
5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de
sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer
un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance
de quelle maière les disques vont être 'décalés', on n'à que les étapes
4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui
doivent probablement ajouter une couche de problèmes.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.chainon-marquant.org
http://newsportal.chainon-marquant.org
http://news.chainon-marquant.org
Le 01-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance de quelle maière les disques vont être 'décalés', on n'à que les étapes 4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui doivent probablement ajouter une couche de problèmes.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
YBM
Le 02.04.2012 03:01, Doug713705 a écrit :
Le 01-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance de quelle maière les disques vont être 'décalés', on n'à que les étapes 4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui doivent probablement ajouter une couche de problèmes.
Quand tu ajoutes un disque SCSI (à froid) à un système en place tu t'attends à ce que le démarrage suivant échoue ? C'est ce qui se passe avec rhel 6 si tu mets des /dev/sd.. dans fstab et la conf de GRUB.
Une fois que tu as modifié la conf de grub et fstab, partitionné le disque, formaté les volumes, mis à jour fstab et que tout roule, tu t'attends à ce que le prochain reboot programmé, des mois plus tard échoue ?
C'est ce qui se passera avec RHEL 6 si tu mets des /dev/sd.. dans fstab...
Le 02.04.2012 03:01, Doug713705 a écrit :
Le 01-04-2012, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis
débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les
noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait
inscrire dans le fichier /etc/fstab étaient stables face à des
modifications du système tels qu'un changement ou une suppression de
disque. C'est tout.
Qu'est ce qu'il y a de génant à :
1 - Ajouter/supprimer un disque
2 - Comprendre l'origine du problème si problème il y a (dans
l'hypothèse d'un comportement non prédictibe)
3 - Remettre la configuration dans son état initial
4 - Modifier fstab en fonction des informations qu'on a récupéré à
l'étape 2
5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de
sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer
un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance
de quelle maière les disques vont être 'décalés', on n'à que les étapes
4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui
doivent probablement ajouter une couche de problèmes.
Quand tu ajoutes un disque SCSI (à froid) à un système en place tu
t'attends à ce que le démarrage suivant échoue ? C'est ce qui se
passe avec rhel 6 si tu mets des /dev/sd.. dans fstab et la conf
de GRUB.
Une fois que tu as modifié la conf de grub et fstab, partitionné
le disque, formaté les volumes, mis à jour fstab et que tout roule,
tu t'attends à ce que le prochain reboot programmé, des mois plus
tard échoue ?
C'est ce qui se passera avec RHEL 6 si tu mets des /dev/sd.. dans
fstab...
Le 01-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Le 02/04/2012 00:15, Nicolas George a écrit :
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Par le Croquemitaine pendant la nuit ?
Peu importe, la question (en ce qui me concerne) était de savoir si les noms des partitions (comme /dev/sda1 par exemple) que l'on pouvait inscrire dans le fichier /etc/fstab étaient stables face à des modifications du système tels qu'un changement ou une suppression de disque. C'est tout.
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Evidement si le comportement est prédictible est qu'on sait à l'avance de quelle maière les disques vont être 'décalés', on n'à que les étapes 4 et 5 à gérer.
Ceci dit, je n'ai aucune expérience des systèmes RAID et autres LVM qui doivent probablement ajouter une couche de problèmes.
Quand tu ajoutes un disque SCSI (à froid) à un système en place tu t'attends à ce que le démarrage suivant échoue ? C'est ce qui se passe avec rhel 6 si tu mets des /dev/sd.. dans fstab et la conf de GRUB.
Une fois que tu as modifié la conf de grub et fstab, partitionné le disque, formaté les volumes, mis à jour fstab et que tout roule, tu t'attends à ce que le prochain reboot programmé, des mois plus tard échoue ?
C'est ce qui se passera avec RHEL 6 si tu mets des /dev/sd.. dans fstab...
Francois Lafont
Le 02/04/2012 03:01, Doug713705 a écrit :
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Rien de gênant dans tout ça en effet.
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Il a dit tout ça ? :-) Et bien je suis d'accord et je ne pense pas avoir dit le contraire à un moment donné.
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario. Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID. Mais où est le problème dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
-- François Lafont
Le 02/04/2012 03:01, Doug713705 a écrit :
Qu'est ce qu'il y a de génant à :
1 - Ajouter/supprimer un disque
2 - Comprendre l'origine du problème si problème il y a (dans
l'hypothèse d'un comportement non prédictibe)
3 - Remettre la configuration dans son état initial
4 - Modifier fstab en fonction des informations qu'on a récupéré à
l'étape 2
5 - Refaire la modif et s'apercevoir que tout roule normalement
Rien de gênant dans tout ça en effet.
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de
sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer
un minimum.
Il a dit tout ça ? :-)
Et bien je suis d'accord et je ne pense pas avoir dit le contraire à un
moment donné.
Encore une fois, je me posais simplement la question de la stabilité des
noms comme /dev/sda1 etc. dans un certain scénario (ajout puis
suppression de disque), c'est tout. YBM m'a apporté un élément de
réponse (basé sur une expérience personnelle apparemment) qui semble
indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans
un tel scénario. Pour ma part, ça m'incite juste à penser que dans
fstab, il est alors préférable de mettre l'UUID. Mais où est le problème
dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
Qu'est ce qu'il y a de génant à : 1 - Ajouter/supprimer un disque 2 - Comprendre l'origine du problème si problème il y a (dans l'hypothèse d'un comportement non prédictibe) 3 - Remettre la configuration dans son état initial 4 - Modifier fstab en fonction des informations qu'on a récupéré à l'étape 2 5 - Refaire la modif et s'apercevoir que tout roule normalement
Rien de gênant dans tout ça en effet.
Comme le souligne Nicolas, personne (en tous cas pas quelqu'un de sérieux) ne s'amuse à débrancher/échanger des disques sans s'y préparer un minimum.
Il a dit tout ça ? :-) Et bien je suis d'accord et je ne pense pas avoir dit le contraire à un moment donné.
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario. Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID. Mais où est le problème dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
-- François Lafont
La Bete des Vosges (Francis Chartier)
Le Mon, 02 Apr 2012 03:33:28 +0200, Francois Lafont a écrit :
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario.
Testé il y a 2 jours sur une grappe raid1 (/dev/sda+/dev/sdb). Redémmarrage après débranchage de /dev/sda : /dev/sdb devient /dev/sda mais le système démarre normalement, mdadm signale que la grappe est dégradée. Le fichier fstab référence les partitions par leur UUID.
Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID.
Je le pense également. J'ai pour habitude de rajouter en commentaire la mention /dev/sdx d'origine. De la même manière que les disques portent le numéro du port sata sur lequel ils sont branchés.
-- La Bête des Vosges
Le Mon, 02 Apr 2012 03:33:28 +0200, Francois Lafont a écrit :
Encore une fois, je me posais simplement la question de la stabilité des
noms comme /dev/sda1 etc. dans un certain scénario (ajout puis
suppression de disque), c'est tout. YBM m'a apporté un élément de
réponse (basé sur une expérience personnelle apparemment) qui semble
indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans
un tel scénario.
Testé il y a 2 jours sur une grappe raid1 (/dev/sda+/dev/sdb).
Redémmarrage après débranchage de /dev/sda : /dev/sdb devient /dev/sda
mais le système démarre normalement, mdadm signale que la grappe est
dégradée.
Le fichier fstab référence les partitions par leur UUID.
Pour ma part, ça m'incite juste à penser que dans
fstab, il est alors préférable de mettre l'UUID.
Je le pense également. J'ai pour habitude de rajouter en commentaire la
mention /dev/sdx d'origine.
De la même manière que les disques portent le numéro du port sata sur
lequel ils sont branchés.
Le Mon, 02 Apr 2012 03:33:28 +0200, Francois Lafont a écrit :
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario.
Testé il y a 2 jours sur une grappe raid1 (/dev/sda+/dev/sdb). Redémmarrage après débranchage de /dev/sda : /dev/sdb devient /dev/sda mais le système démarre normalement, mdadm signale que la grappe est dégradée. Le fichier fstab référence les partitions par leur UUID.
Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID.
Je le pense également. J'ai pour habitude de rajouter en commentaire la mention /dev/sdx d'origine. De la même manière que les disques portent le numéro du port sata sur lequel ils sont branchés.
-- La Bête des Vosges
Doug713705
Le 02-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario. Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID. Mais où est le problème dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
Rien en fait, juste dire que changer un disque dur ce n'est pas simplement brancher une souris ou un écran et que ça reste une opération 'délicate' qu'il convient de faire une fois qu'on y a bien réflechi.
C'est cette reflexion préalable qui permettra d'éviter les déconvenues qui en tant que telles ne sont pas gravissimes.
Ceci dit, j'ai une utilisation assez simple des disques durs qui me permet de ne pas utiliser de RAID ni de LVM et je n'ai pas non plus d'UUID dans mes fstab ;-)
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Le 02-04-2012, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
Encore une fois, je me posais simplement la question de la stabilité des
noms comme /dev/sda1 etc. dans un certain scénario (ajout puis
suppression de disque), c'est tout. YBM m'a apporté un élément de
réponse (basé sur une expérience personnelle apparemment) qui semble
indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans
un tel scénario. Pour ma part, ça m'incite juste à penser que dans
fstab, il est alors préférable de mettre l'UUID. Mais où est le problème
dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
Rien en fait, juste dire que changer un disque dur ce n'est pas
simplement brancher une souris ou un écran et que ça reste une
opération 'délicate' qu'il convient de faire une fois qu'on y a bien
réflechi.
C'est cette reflexion préalable qui permettra d'éviter les déconvenues
qui en tant que telles ne sont pas gravissimes.
Ceci dit, j'ai une utilisation assez simple des disques durs qui me
permet de ne pas utiliser de RAID ni de LVM et je n'ai pas non plus
d'UUID dans mes fstab ;-)
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
http://usenet-fr.chainon-marquant.org
http://newsportal.chainon-marquant.org
http://news.chainon-marquant.org
Le 02-04-2012, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
Encore une fois, je me posais simplement la question de la stabilité des noms comme /dev/sda1 etc. dans un certain scénario (ajout puis suppression de disque), c'est tout. YBM m'a apporté un élément de réponse (basé sur une expérience personnelle apparemment) qui semble indiquer que non, dans l'absolu, c'est n'est pas forcément stable dans un tel scénario. Pour ma part, ça m'incite juste à penser que dans fstab, il est alors préférable de mettre l'UUID. Mais où est le problème dans tout ça ? Je ne vois pas trop ce que vous cherchez à démontrer en fait.
Rien en fait, juste dire que changer un disque dur ce n'est pas simplement brancher une souris ou un écran et que ça reste une opération 'délicate' qu'il convient de faire une fois qu'on y a bien réflechi.
C'est cette reflexion préalable qui permettra d'éviter les déconvenues qui en tant que telles ne sont pas gravissimes.
Ceci dit, j'ai une utilisation assez simple des disques durs qui me permet de ne pas utiliser de RAID ni de LVM et je n'ai pas non plus d'UUID dans mes fstab ;-)
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) http://usenet-fr.chainon-marquant.org http://newsportal.chainon-marquant.org http://news.chainon-marquant.org
Emmanuel Florac
Le Sun, 01 Apr 2012 23:20:47 +0200, Francois Lafont a écrit:
Oui mais s'il y a ajout d'un nouveau disque sur le système puis débranchement d'un ancien ?
Je l'ai fait plusieurs fois, pas de problème particulier. En cas de doute on peut toujours éditer les fichiers dans /etc/udev/rules.d .
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Sun, 01 Apr 2012 23:20:47 +0200, Francois Lafont a écrit:
Oui mais s'il y a ajout d'un nouveau disque sur le système puis
débranchement d'un ancien ?
Je l'ai fait plusieurs fois, pas de problème particulier. En cas de doute
on peut toujours éditer les fichiers dans /etc/udev/rules.d .
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
